Defense in Depth for AI: Fundamentals, Tools, and People with James Hengsterman-Cash - Ep 251

James Cash IMAGEJames Hengsterman-Cash is the CISO at Unison, which provides software and services, often as a SaaS provider, that simplify complex government problems, from managing major programs, contracts, acquisition, and grants to cost engineering. He has spent 20 years in the field, works in a highly regulated space, and also teaches executive courses on AI and security. James and Matthew examine how fast AI adoption is changing risk for a technology company that serves government customers, and where AI genuinely helps defenders. The conversation moves from security fundamentals and in-house models to tool costs, security that stays out of the user’s way, and keeping skilled people at the center.

 

apple
spotify
stitcher
google podcast
Deezer
iheartradio
tunein
partner-share-lg

Here’s a glimpse of what you’ll learn: 

 

  • Why James compares today’s AI adoption to the open S3 bucket stage of cloud
  • How more unknown unknowns still lead back to security fundamentals
  • Where AI helps defenders, from alert fatigue to red teaming alongside humans
  • Why a highly regulated company cannot use every new startup tool
  • What an in-house model needs in guardrails and AI expertise
  • Why code review is a strong place to start with AI
  • How model routing and tokenomics help match models to tasks
  • Why an accountable human who understands the systems stays essential

In this episode…

James cites a 2025 report saying only 8% of companies lacked an AI feature on their road map, and he describes the current moment as the open S3 bucket stage, with more unknown unknowns to account for than before. Pressure arrives from several sides: more discovered vulnerabilities, some sloppy coding, and a push to adopt AI internally for business productivity and for customers. At Unison, code is reviewed in the pipeline, and he keeps returning to fundamentals such as patching systems and deploying secure code. He calls AI a fantastic tool for specific use cases, including alert fatigue, and says pen testing and red teaming need both AI tools and humans, because each catches things the other misses. In a highly regulated space only a subset of tools qualifies, since trust and organizational maturity matter. On bringing models in house, James says larger organizations need someone who understands AI and not just LLMs, and that a frontier model deployed internally without the right guardrails introduces a malicious insider.

James thinks some AI fatigue is self-inflicted, because organizations pushed AI into places where it was not useful, much like the Google search bar that once appeared on every corporate intranet. He sees code review as a better starting point, since peer reviews do not happen at the level these systems can reach, and he argues that engineers with AI can multiply their output instead of being treated as headcount to cut. On cost and training, he points to model routing tools that match each task to the right model, notes that tokenomics keeps coming up, and says training cannot keep pace when the field changes every couple of months. His answer is to make the secure path the easiest one, as SSO did. He dislikes the phrase that security is everybody’s responsibility, says security is security’s responsibility, and argues that a phishing click that compromises a network is not the user’s failing. Because these models are non-deterministic, some things will still slip through, so he falls back on defense in depth. He adds that adoption spread over years instead of months could have given the industry time to prepare for issues like prompt injection.

In the SOC, James describes an AI system that reports how confident it is in an alert so an analyst can look deeper and escalate to Tier 2. For a small business with no security team, he says that beats having nobody review logs and alerts. He hopes SOCs do not disappear and that AI takes over tier 0 triage, and he wants a human who is accountable and understands these systems, noting that no system gets the sinking feeling that makes an experienced engineer stop and double check before a production change. He worries about organizations that ingest compliance and policy documentation into a system and are left with nobody who understands it. He also describes a colleague on his governance team who is not a developer and built a separation of duties and privileged access management tool, which shows the cross-functional reach AI now gives practitioners. On the future of roles, James says people are part of defense in depth, asks what happens when senior analysts leave if no junior pipeline exists, and hopes AI is adopted in tandem with people so each person can deliver far higher quality work. Once the models improve, he says, it is the responsibility of security practitioners and technologists to use them to make things better.

 

 

Resources mentioned in this episode

 

Matthew Connor on LinkedIn
CyberLynx Website
James Hengsterman-Cash on LinkedIn
Unison Website
Darktrace Website
Abnormal AI Website

 

Sponsor for this episode...

 

This episode is brought to you by CyberLynx.

CyberLynx is a Bethesda managed IT and cybersecurity company. Local techs you know, not a call center. Month-to-month. 24/7 intrusion detection.

We help growing companies with managed IT, help desk, backup and recovery, and a fractional CIO.

Talk to us at https://cyberlynx.com/contact, info@cyberlynx.com, or 301-798-9170.

 

Check out previous episodes:


Everybody Has an AI Idea and a Tool, but Not Every Shoe Fits with Steve Goudreau - Ep 250

Smart People Know You Can’t Just Let AI Do Everything with Brian Walters - Ep 249

Why Fear of AI Hands the Bad Guys an Edge with Jason Stockinger - Ep 248 

 

Transcript: 

 

Cyber Business Podcast

James Hengsterman-Cash

CISO

Unison


Matthew Connor: Matthew Connor here, host of the Cyber Business Podcast. Today we're joined by James Hengsterman-Cash, CISO at Unison. James, welcome to the show.

James Hengsterman-Cash: Thanks so much for having me.

Matthew Connor: Thanks so much for being on the show today. Before we get too far in, a quick word from our sponsor.

Sponsor Break: CyberLynx. Hackers are using AI to conduct machine-speed attacks. Is your security keeping up? CyberLynx sells industry-leading AI-powered cybersecurity solutions that detect threats in real time, so you know about an attack before the damage is done, not after. Learn more at cyberlynx.com. That's cyberlynx.com.

Matthew Connor: And now back to our show. James, for those who aren't familiar, can you tell us about Unison and your role there as CISO?

James Hengsterman-Cash: Absolutely. Unison has been around for a while. We provide software and services, often as a SaaS provider but not always, to simplify complex government problems. That means helping manage major programs, contracts, acquisition, grants, and cost engineering. We help them do that securely and efficiently so those folks can stay focused on the mission.

Matthew Connor: I love it. One of the things I noticed is you guys are leveraging AI in your product offerings, right?

James Hengsterman-Cash: Aren't we all?

Matthew Connor: Well, not everybody, though I do believe everybody should be. Can you walk us through that a little bit? We're in this fascinating time with AI. I think we're beyond infancy and we're in the toddler years, where it's so early on. The technology was perhaps exciting for the first few years, but it was really challenging to maximize ROI and get the results people were looking for. If we hold that analogy, I think these are really smart toddlers, little genius toddlers, doing amazing stuff now. But on implementation, every company is thinking about how to implement this. I think it's really interesting to talk to people who are doing it. They're the tip of the spear, as we'd say in the Army, out front, living it every day. Can you walk us through what that looks like, how it works, and some of the trials and tribulations from the early days?

James Hengsterman-Cash: Sure. There's a lot in there. First, in 2025 there was a report that basically said only 8% of companies didn't have an AI feature on the road map, at least. Some of that was road map, some of it was actually implemented, so we're seeing really high levels of adoption. And you're right that we're in the toddler stage, but maybe a more direct comparison is that we're in the open S3 bucket stage. I think we would see similar issues if the push to cloud, which was a 10-year cycle to get most everybody moved, had been a six-month thing where you said, "Hey, everybody get in." That would have caused things like an open S3 bucket for one company that everybody had a chance to learn from and improve upon. Now every company's there, and a lot of this is about handling that risk in a way that accounts for more unknown unknowns than we've had to in the past.

A lot of it comes back down to security fundamentals at almost every level, now more complex than that, obviously. We're getting hit from a few sides. One is more discovered vulnerabilities, and more vulnerabilities created by maybe some sloppy coding. On the other hand, we're being pushed to adopt this internally for business productivity. By "we," I mean the industry. We're being pushed to be teched out. We're technology companies, at least in this space, and we should be seen as on the leading edge of that wave. So there's pressure: there's this new technology, and we should be adopting it for our customers and for the sake of the business. There are a lot of different vectors coming into play that are really tricky.

Just the vulnerability piece ties well to security fundamentals: patch your systems, deploy secure code. We've seen a couple of huge spikes, last month and the month before, some really big spikes, and hopefully that's not the new norm. You would think that if these systems are as effective as they're purported to be, we should see fewer vulnerabilities deployed from the onset. It's not great that it's finding all of these, some very old, some new zero days coming out at the same time. On the other end, in our pipeline, we're making sure the code is reviewed, and hopefully our quality of code is increasing from an already fairly high level.

Matthew Connor: When you look at vulnerabilities, with the speed of adoption of AI on both sides of the battle, good versus evil, I think it's fascinating that you touched on the older exploits. Rewind 10 or 15 years and you could take a lot of comfort in knowing you were up to date on your firmware and your software. You're fully patched, you're great. Save for a handful of uber hackers in the world, you were safe. Today I don't think we can trust patching like we used to. You can't depend on it. I know this goes back to the fundamentals to some degree, but I wonder, because of this modern zero-day threat, some kid in Lithuania, and I'm not sure why I always call it some kid in Lithuania, but I've got it in my head, some kid in Lithuania with a prompt who's going to come up with a zero-day exploit for whatever. I think that's a very real possibility these days. We've seen it.

So how does that shift the defensive landscape? Yes, there are the fundamentals, but do we need to shift what the fundamentals look like, fighting fire with fire? Does there need to be some sort of AI we're leveraging, like Darktrace, where you're looking at the entire network and seeing the activity and saying, "Oh, this is weird, let me stop this"? Or is it using products that look for vulnerabilities? What's the future like, today? Because I think we live in the future. What should CISOs and other security leaders be looking at in terms of how to defend their organizations from these zero-day attacks?

James Hengsterman-Cash: I've had similar conversations to this one. You probably remember when Metasploit came out, basically saying, "Well, we're toast now," if any script kiddie can pull up and understand every vulnerability impacting a system. But you're right, fighting fire with fire, to use the old adage, just burns the world down. But no, you're right. The adversarial nature of cybersecurity means we need to try to make this as asymmetrical as possible. So yes, we absolutely need to be using these tools. Unsurprisingly, being in the space, I'm a technology optimist, and I think AI is a fantastic tool for specific use cases. It depends on those use cases, but it is a fantastic tool for them.

One of those, which for a long time was just a growing problem in security, is alert fatigue. If you could have a SOC analyst who spends five minutes on every alert you get, that would be great, but nobody had been in that space for a long time. So we use these tools to try to tip the scales. But we're still running into the problems, both from a protective stance, and it's always been the case that our adversaries only need to be right once. They only need to get lucky once. They need to catch one bug in the software, one exploit chain that wasn't caught by vulnerability scanners. But yes, unfortunately, we need to.

I've only been doing this for 20 years, but over the past 20 years it's always been that the technology gets better, the job gets harder, the job expands. This is the same thing. When we do pen testing now, when we pen test our models and do red teaming against our systems from an AI perspective, we need to use these AI tools to catch these things. At the same time, we also need to have humans do it. Those people will often catch things the AI missed, and the AI will, as we've seen, catch lots of things the humans missed. So unfortunately the scope of work just expands, and being in the highly regulated space gets even trickier, because there's only a subset of tools we can even use. We can't use every startup with two people in a basement out of Santa Clara, because there's the trust piece, the organizational maturity, all sorts of things. That makes it tough to do.

There are some really interesting ones, CrowdStrike, and I think SafeMind [unclear], but there are other providers doing something similar where you're seeing some really advanced adversarial models, which are great. But one of my concerns is what that means. Does that mean a larger company can afford to pay for those and to test? Does security become pay to play, where only major providers can afford to do it? Because these things are expensive to run and to maintain. Even if some of the big providers, Anthropic and OpenAI and everyone else, wanted to be generous and say, "Hey, we'll help municipalities run these things for free," that's a really expensive proposition, especially given that they're trying to make money.

Matthew Connor: I can't help but wonder, right now in September 2026, we're in this really interesting place. I think it was Apple, last month, that did a little demo where they used four Mac Studios connected together to run Kimi 2.6. Now, mind you, that's $20K of hardware, but you're running a near-frontier model in house for a relatively small sum compared to what you would traditionally expect to pay, closer to $100,000. I think we're starting to see an economic shift, and I think that's kind of Apple's focus moving forward. It'll be really interesting to see how this affects the industry and the market.

If we're starting to see hardware improve in performance and drop in cost, and models become more efficient, like Jev [unclear], I don't know if you saw that just came out, which is super cool because it's so small and so fast, then using a combination of models and moving this in house, does this lead us to a place where, let's say in the government space, where it is so highly regulated, because you bring this all in house, we're going to see smaller organizations be able to run all of their stuff in house without massive expertise? Because one AI helps us leverage AI, that's just the reality of it. You don't need somebody with a doctorate in it, because there's no such thing, really. It's all advancing so rapidly. Is that the direction we're going? Is that on your road map, or will we be able to bring this stuff in house in a more affordable way? Because we can't really rely on the two-person startup, but we could do this in house.

James Hengsterman-Cash: More affordable is a complicated proposition, especially when you're bringing something like that in house. I think you're right that we don't need experts in all cases, but if you're a bigger organization, you should have somebody who understands AI, not just LLMs. Writing a bunch of code doesn't mean you understand. You might understand the output from an LLM, but to secure these systems, just like our other systems, you need to understand them at a really fundamental level. To secure a cloud environment, you need to understand the cloud. To secure IT systems, you need to understand those systems. So I think we do need more AI-specific expertise to help deploy these things.

There are a couple of points. One is that you're right, we're seeing not necessarily a logarithmic increase but a pretty linear increase in how these models perform, along with their token burn rates. With that, though, we are seeing distillation of the models. We're seeing that a lot overseas, and I think there are some lawsuits out about that now. So we are going to see really advanced models. It's the history of computing: they're going to get smaller, they're going to be more efficient, and we are going to see both organizations and adversaries have these advanced models.

The problem is when an inexperienced organization deploys one. Say you could deploy a frontier model in a data center that you control. That's great. But if you can do that, chances are the adversary can do that. The adversary can make mistakes. They can let the raw model run and do things it shouldn't. If you deploy that internally without the right guardrails and things in place, you've now introduced basically a malicious insider, which is its own set of problems. So that is tough. I don't know exactly where the gap sits between COTS models and the frontier models you can deploy internally, but I think that gap is getting smaller than it used to be. So I think we are going to start seeing that trade-off of people deciding, "Well, maybe we don't need the frontier model." At the same time, as a security team, does that get us enough edge on adversaries? I don't know the answer to that.

Matthew Connor: It's a really fun time, because as we see the frontier models continue to get more and more advanced, I think they're currently at a really functional level. I think for a lot of people who got into it early on, they tested it, they were disappointed, and that left them with a bad taste in their mouth. It's just not ready. It hallucinates. I'm talking about knowledge workers, a lot of whom were pushed to try to use it early on. It didn't work as well as expected, and I think that left a lot of people disappointed or jaded about its abilities. Today there's still a sizable portion of the population that sees it as not as good as they are, it hallucinates, whereas the models now are so much better than they were four years ago.

To get people to keep coming back and testing every six months, people just aren't used to it. We in the tech field like that stuff. We're like, "Yeah, cool, it changed from last week." But most people who aren't in technology don't like rapid change. And interestingly enough, a lot of people in tech don't like change either, which always blows my mind. I'm like, you might not be in the right field. So is there this adoption, I don't want to say fatigue, but this misperception, psychologically, for a lot of users? They have an impression of ChatGPT 1 versus the new, whatever, 6, or their new Fable 5.1. We're in a different world completely than where we were when people were initially introduced to AI. So is there a challenge in getting them to reassess?

James Hengsterman-Cash: Some of it, I think, is a little bit self-inflicted. I think we probably start with GPT-3, which was released in November 2022, I believe. And there are definitely still some issues. If you are an expert in your field, or better than the average expert in your field, it might take you longer, but your output can probably be better. If you had one of the top five pen testers for OpenBSD running checks on OpenBSD, they probably would have found vulnerabilities as well.

I think the self-inflicted piece is this: do you remember when everybody put a Google search bar on every corporate intranet site? Everything you went to just had a Google search bar at the top. I think some of it is that organizations are trying to use these tools where they're just not useful. There's a whole push to use it, and then people use it and say, "This isn't that helpful." Even earlier on, it's much better at writing code now, but earlier you'd give it to a really good developer and they would say, "This is terrible. This isn't useful." And even now, I don't think anybody would say AI writes extremely efficient code. It's effective, but it's not always the most efficient. Something that could be a simple Python script of a couple of lines is going to be 100 lines of code, and there are trade-offs to that. It does comment code, which I don't think happens nearly as often as it should.

Code review is a great example of where it is great. If more organizations had started with, "We're just going to introduce this to review and suggest improvements to code," even the earlier models were fantastic at that, because let's be realistic, peer reviews are happening, but not at the level these systems can do it. If people had leveraged this and then had the peer review, that would have prevented the issue. We saw a lot of companies saying, "We need fewer software engineers," and I think that was a really big mistake, because I've never met a development team that says, "I guess we're done for the day. It's 2:00 PM and we finished all the things we need to do." Some people say we need fewer software engineers, when really it's, "No, now we have a bunch of software engineers who can improve their output, or who don't have to do peer reviews or can do these other things." So you can multiply your output.

I think that's where some of the fatigue came from: these being pushed. Not to pick on Adobe, but every time I open a PDF, I don't need it to ask me to summarize the page. I can read a couple of sentences. It's not that big of a deal. And it's not the organization's fault either. I'm sure they had pressure internally to roll out features. There's pressure to release these. You need to be seen as cutting edge. People want to say, "We're using the newest and greatest AI models in our tool set."

Matthew Connor: I think you raise a really brilliant point, and sure, hindsight being 20/20, but I think we can learn from it. The peer review thing is still a really smart thing today. Having the code review from the AI, I think, would help with adoption. I think it would help get developers really behind it. I think you could also make the business case. And I think this was a failure on the technologist, on the IT side, to not have pushed back and said, "Hey, look, we've explored it, and it doesn't write the best code. We're not there yet for replacing or fully augmenting our software engineers. But where it's really great is code review, so we can put out better, safer code. This will free up their time to work on other things they're good at." This is a good thing, and it will help us improve our products, and eventually we'll get to that point.

I think the pushback should have been there, and maybe some organizations did push back. But we see great examples like Meta, where that was not the case, where they thought, "Yeah, we get to fire 10,000 people because we have AI now." Sure you do, Mark. How'd that go for you? Not so great. That's a really extreme example of what most businesses thought or think: "Hey, look, this is great. We can reduce our headcount. We can be more productive with fewer people thanks to AI." We're not there yet. And I also think that's probably the wrong perspective for software engineers and probably most jobs. I don't think it's a matter of how many people we can replace, but how much more we can do with what we have. How much better can the output quality be? How much happier and better can the employee's day be? How much more productive can they be? If they're doing twice as much and it's twice as good, fantastic. You've doubled your workforce, you've doubled your output, in ways quadrupled, because it's better quality.

James Hengsterman-Cash: Yeah, and you saw that. A lot of organizations lost a competitive advantage. I'll simplify the math here, but take two organizations, both with 10 software engineers. One doesn't get rid of anybody and gives them all the ability to use AI to improve their job. The other company says, "We can do the same amount of work with half the engineers, so we're down to five." Now the original company has so much more output, and you lose that competitive edge, while the other company is staying still by saying, "We can improve efficiency here." Especially in the SaaS world, maybe there is and I'm not aware of it, but I don't think there's any software that's perfect from every user's perspective. There just isn't. So you're always going to have ways to improve, even from an efficiency standpoint.

So yeah, you're absolutely right, there should have been more pushback. But it's tough, because we're discussing AI, and we've seen change. When I was initially pitched, it was all machine learning and neural nets, which were fantastic. They have amazing use cases that still far exceed some of what you can do with these LLMs, but it's complicated. It's really math intensive. You do need a PhD to really understand those systems in a lot of cases. An LLM, anybody can understand. Almost any end user can understand how it works. It feels like a little bit of a magic trick. So when there's a new technology that's going to get better, the way all technologies do, of course you have technologists who say, "Yeah, let's adopt it. This looks cool," not realizing that some of the problems are harder to solve. There are some things that ended up being more difficult to solve with an LLM than people were expecting.

Matthew Connor: And we're seeing that now, especially with the significant increases in pricing that these major frontier model providers are kicking out. We're seeing people step back and say, "OK, where is this actually useful? Maybe we don't need everybody with the Max plan, just setting tokens on fire. Let's take a step back and figure out where this works. Maybe your most advanced models are only used by your senior developers or your senior engineers." I think that's a good direction, and it does seem like some folks are moving that way. Even then, that skill of what we'll call token management is a new skill. It's a new everything.

So instead of just using your, whatever you want to call it, Fable 5.1 for everything, teaching your entire organization how and when to use which model is a challenge in and of itself. I'm not sure it's in their best interest, but I think it would be great if, when Anthropic or ChatGPT releases a model, it were built in, where the leading model, since it's great for reasoning and planning, says, "Great, I'm going to do the planning, and then I'm going to spin up a sub-agent with the right model for this task," and does that for all tasks. That's how it should come out of the box. It would be great, but instead that has to be taught and put into practice everywhere in an organization. I think it's challenging for people to go through and get that experience, that knowledge. And I'm not sure how you do it at scale when you've got hundreds if not thousands of people. How are you going to train them all on that? It was hard enough getting them to start using it.

James Hengsterman-Cash: Absolutely. We're seeing, as with anything, that need you just elucidated across the industry. And we are seeing providers come up with model routing tools that do that exact thing and say, "You don't need the Max effort frontier model to respond to this email about when you're going to take lunch. That's not useful. You can use the most basic, highly efficient model, or you can switch out the provider." I've heard the term tokenomics come up quite a few times recently, and I think that's exactly what a lot of these organizations need.

We've seen this in security. One of my least favorite phrases is "security is everybody's responsibility." It's the same thing with this tooling. Maybe your organization's great and you can tell all your users, "Use X.1 for these types of tasks and X.5 for these types of tasks." But then two months later, everything's changed. This field is moving so quickly that even if you were to train people, you'd have to have a weekly webinar to cover these things. And it's the same in security: it's more secure when the default path, the easiest path folks want to take, is the secure one. We saw that with SSO. SSO is one of my favorite examples because it's one of the very few times security was able to say, "We're going to make this more secure and make your life easier at the same time." Normally that's not the case.

Matthew Connor: I'm curious what you think on this. I think SSO is a really great example of security done right. When we get the right tools and it's implemented, it takes the security aspect away from the end user and just does its job. As an industry, because we were limited by the technology we had, we had to share the responsibility with the end users. It's a hot take, but I think thanks to AI we're moving in the direction, and will at some point in the not-too-distant future, be able to remove security from the end user altogether and not have to worry about security awareness training or anything like that, because we will be able to do it fully on our end so it's seamless for them. The email is not going to come. There won't be any malicious email that gets through, zero. They won't have to worry about clicking on something. Taken care of. They won't have to worry about anything in terms of security, because there will be an agent taking care of that to ensure that Jane in accounting gets to do accounting only and doesn't also have to be concerned with cybersecurity.

I like that idea of the future. And I think SSO is a great example: when we have the right tool and we implement it, it becomes super easy for the user. They say, "I just logged in. I don't know." They don't even understand how much better the security is. I think we'll get to that. But I'm curious, because I am an AI optimist, do you think I'm overly optimistic in that, or do you see it happening like that or differently? What do you think?

James Hengsterman-Cash: I really like that take. I'd take it one step further. I think that's already our job. Like I said, I really don't like the phrase "security is everybody's responsibility," because it's not. You don't get your finance team coming out every month saying finance is everybody's responsibility. It kind of is, we all have responsibilities, but it's not actually. Security is security's responsibility. That's why we're here. If a phishing email gets through and a user clicks on it and a single executable can compromise your entire network, that's not a failing on the user's part. A lot of their job is clicking on links, and phishing is really tricky. If you send me an email, that's what I'm expecting, and I'm expecting a link in it, and it's from people I'm expecting. The tools don't catch it. I'll click on a link. We onboard folks and say, "Be careful about clicking on links. Here are 100 links you need to set up your pay and do everything else."

So I think AI hopefully will help with that. With all of this technology, it will also make it more difficult. If only the good guys had AI, then the answer would absolutely be yes. Unfortunately, I think it's going to be a give and take. But I think that's the way the industry needs to move: if there's a threat path for something and you can remove it from your users' thought patterns whatsoever, that's absolutely the way to handle it. And I think with AI that will get easier. I would love it if the users only had to log in, sit down, open their computer, get to everything they need to do their jobs efficiently, and never have to think about anything. They know everything that comes through is going to be safe. I think this will help.

Part of the problem, though, is that these models are stochastic, or nondeterministic. Even in the best-case scenario, there still will be slip-ups, and things will still get through. But then we fall back on defense in depth, which is as old as warfare, if not older. Nothing's going to work 100% of the time. Even these advanced models, if you've got one running locally on your network, checking all access, doing all these great things, your threat footprint is going to be way, way down, but stuff will slip through. Lock picking is a pretty common hobby in this field, and almost every lock can be picked, because it's intended to be opened with a key. Even if you have a lock and a guard there, it's better, but it's not foolproof. But yes, I think your point about moving away from the end user should be the goal. For other organizations that do other work, not corporate or commercial, private industry work, it's absolutely the direction we need to head.

Matthew Connor: I think we kind of see it in self-driving cars right now. Tesla came out with the stats about a month ago. Now it's eight times, as of right now, and it's not fully there, but it's so much better. It's eight times safer than the average human driver. And its response time is like .13 seconds, something like that. Humans are not that fast. Even Formula One racers are not that fast. You cannot beat the computer in that. You see it in how well it reacts. Is it perfect? No, but I think the analogy holds, because if every other car on the road is a bad guy, they swerve into your lane, they have accidents, they're the threat, and it's constant. That gives us a real-world visual of how AI can protect us against all of these adversaries. And sure, they're not actively coming at us, but neither is every adversary. Sometimes it's passive. Sometimes it stumbles upon you, sometimes you stumble upon it. I think it gives us a pretty accurate analogy.

And now you can clearly see the trajectory. I don't drive anymore. It's ridiculous. About a couple of months ago we were driving and this car swerved into our lane. We're on Full Self-Driving. It happened so fast that, one, I couldn't react fast enough to get out of the way, and even if I had, I would have probably overreacted, thrown us into the median, and slammed on the brakes. The car behind us would have hit us. We'd have been in an accident. This thing was so brilliant, so smooth, so fast that it looked like it was dancing with the other car. It was like this was all planned, because it was incredible how it slowed down just enough. The car didn't hit us. We didn't overreact. The car behind us didn't hit. I was like, OK, I'm done. I saw the whole thing happen. I couldn't move fast enough, I couldn't have taken over. I'm done driving.

We're at that level now, where we're 95% of the way there to full self-driving being what everybody envisions of this perfect system. And we're not quite there with AI yet in terms of the office worker, knowledge work, security, and everything else it's doing outside of driving cars, which is funny, because you'd think that would be one of the things that comes later. It'd be easier to do it on the computer. But it just worked out this way, that we're seeing it in real time in the real world in cars. But I think we're going to catch up, and we'll get to the point where AI really takes that completely off the plate for the end user. I think we're going to get there in the not-too-distant future.

James Hengsterman-Cash: I think that's a really good analogy for a couple of reasons. I think you see some of the most advanced autonomous vehicle companies using things like LIDAR, and the reality is humans have cameras and that's fine, you understand human vision, but we don't have LIDAR. That's just not a feature we have as people. So you get this really advanced sensing you just don't get anywhere else. And you also see the best adoption. I'm not a car person, nor in the automotive industry, so I don't know for certain, but I would not be surprised if a lot of the lane assist and collision detection, those automated features of these vehicles, have significantly reduced accidents or the severity of accidents. Again, I don't know, but I would absolutely not be surprised if that was the case.

Hopefully there's not the same parallel, because the problem with this is not whether it operates perfectly. You have to hold the system to a higher standard than you hold a person, absolutely. I don't know what the car accident rate is, but if an autonomous vehicle had a 1% increase on that, people are going to say absolutely not, it's not worth it. So you do need to hold them to a higher standard while understanding that you get significant safety improvements a lot of the time in these systems. I think that varies by situation and condition and all of these other things. But human nature is that Black Swan events stick out in your mind. We all know that flying is safer than driving. That's a very standard thing people talk about. But you have more people who are afraid to fly, because the thought of an aircraft accident is much more terrifying than that of an automobile accident. That's a really tough barrier to cross. I think some of the way across is by introducing these hybrid systems.

Like I said, I'm not really a car person, but I would love to hop into my car, have it take me where I need to go, and jump back in and go back. That would be fantastic. And for the safety of my kid, I would hope that by the time she's ready to drive, autonomous vehicles are more common. That's not a super popular thing to say, but it is safer than a human driver. Humans make mistakes, humans get tired, and so do systems. Machines make mistakes, the same way these AI systems do. But if you start rolling out adoption, and I think that could have happened if the adoption rate had been a little bit slower here. So much of the risk in security everywhere else is because everything's moving so quickly and the adoption has been so fast. If we could have rolled it out slower, if we could have learned from others' mistakes or our own mistakes in a way that didn't destroy the organization, that would be better. You saw prompt injection attacks, and that was a huge deal because so many people had adopted these systems without those protections. And you saw indirect prompt injection and [unclear]. If this had been spread out over six years instead of six months, the industry could have put some things in place and figured out ways to do it.

It does feel like we are going to get there again, I assume. Maybe not. Maybe LLMs will be the thing that creates general artificial intelligence, but it seems like there's a technological gap there. So it feels like at some point the cost-to-benefit ratio is going to slow down, and hopefully that gives people a chance to say, "Wow, we could really improve efficiency," when we incorporate it as part of a SOC. Again, humans make mistakes. If you have an analyst going through tens of thousands of logs and they miss something, that's just going to happen. It's human nature. But if you have an AI system going through it and saying, "I'm this confident in this, but maybe take a deeper look at it," and then it gets to the analyst, and they can take a look and escalate it to Tier 2, you can follow that flow. I think that would be amazing if you could count on these systems to do that reliably, and in a lot of cases you can. It doesn't understand, but it is reacting well enough to true positives that we can trust the system to say, "Yes, we're 90% confident it's catching all of the alerts we need to catch."

Matthew Connor: I think the SOC is a great analogy. One of the things I get really excited about is that, as of today, you can easily implement a lot of this stuff. You can build your own SOC so quickly. Let's say you have your EDR, you've got your gateway, you've got your identity, they're all accessible via API. But building out an interface for that, and the logic behind it to actually receive that information and do anything with it, takes a lot of coding expertise and a lot of time. Why would you, when you could just go rent it? Somebody else has already built it out and they're selling it to thousands of people. Go rent that. But today you can build that over a weekend, the infrastructure that ties everything into your systems. I'm not suggesting that people should. But the fact that you can so quickly and easily tie into all of your systems, get that information, tweak it yourself, put together the interface you want, monitor how quickly you're getting those alerts, adjust the logic, all of it, to me that's mind-blowing. It's so cool that we now have this power at our fingertips.

Is it [unclear]? No, and I'm not saying people should do it, because it's too early. But the fact that you can do this, and eventually, in the not-too-distant future, the AI logic and the security aspect of it will be such that in a weekend, or a couple of days at work, you will be able to build out your own AI SOC that is so good, so efficient, and so much better, and it's personalized and you can tweak it, that it won't make sense [unclear]. I apologize to all of the SOCs out there, but I think the writing is on the wall, and it becomes kind of a telephone operator. The AI SOC will replace our current SOCs, because why the heck wouldn't it? If you're a SOC now, even if you're leveraging AI, I think the days are kind of numbered. I think we're going to see a huge transition, because it's going to be so easy once the technology's there, and it's not quite there yet. That's just one example where you can easily put that together and boom, have it all there. Have it self-assessing, self-correcting, self-improving, all of it.

The planning of our own SOC is, OK, it's a lot. But for those organizations that are large enough to have their own internal SOC, you say, "Oh, build your own, you don't have to worry, use this SIEM product." I think that's a really cool example of how we now have these kind of godlike powers at our fingertips when it comes to what we can create. It's just so exciting.

James Hengsterman-Cash: I would say it's more the other way around. If you have a major SOC with 12 to 24 people running it [unclear], it's almost harder to implement these systems because you already have that. It's not harder, it's that the cost-benefit ratio is worse because you already have these experts. But it's definitely better than being a small business with no security team and no SOC, where you can't get a SOC analyst for the 20K a year it takes to run this thing. Absolutely, because it's 100% better than not having anybody reviewing logs and alerts and just feeding them into some system somewhere.

But I think there's a lot of room. I don't expect, and I would hope, that SOCs don't disappear. What I would hope is that, the same way SIEM tools solved the problem of having an analyst go in and pull logs from individual systems and find a way to do that, hopefully the AI systems replace some of the, not tier 1, but maybe tier 0 triage. And there are systems out there which not only say, "Here's an alert," but also, "Here's an alert, and this is why I think you should look at it." That actually helps develop more SOC analysts, because at the end of the day, you could theoretically go up the chain and keep replacing folks. Then you get to a point of, OK, now you have a fully AI SOC, and, talk about this industry, you're in the federal space and you have a DoD or federal agency customer come to you and say, "You've been missing these types of alerts and now we have a data breach." And they'd be like, "What's going on?" And we'd be like, "Well, it's an automated system." And they're like, "Well, that's fine. I don't care who's responsible for it, because I want to send them a subpoena." So you always need, basically, a throat to choke. But you do need a human who is accountable for it and who understands these systems.

One of the problems is that none of these systems, when pushing a major change in production, for example, get that sinking feeling of, "Actually, let me stop, let me double-check." I have all of this experience built in. I've developed an instinct for knowing when we should validate these things or double-check. So at some point you'll need, at least for the next, who knows, six months, this could be terribly outdated, a person there for a lot of these. And I am worried that too many organizations are going the route of replacing the software developers, and with SOCs saying, "We're going to get rid of all of this," or fully ingesting all of our compliance and policy documentation into a system. Now you don't have anybody who actually understands it. You have a model you can ask questions about, but you don't have anyone who understands it and can see when the model missed this, or it was almost right here but wrong in a fatal way.

So I would really like to see a lot of these solutions find a way to say, "We're not saying we're going to hand everything off. We are saying that instead of your SOC spending 80% of their time reviewing logs right now, they're spending their time reviewing alerts, which can then be tuned." Like you said, if somebody's trying to build something, say you were trying to build an automated SOC tool, not only do you need to understand security operations, but you also need to be a developer. Those people do exist, but they don't exist everywhere and they're not exceptionally common. Now you have that ability to say, "Look, I'm a security practitioner. I'm not as spun up on this type of development thing. Let's prototype, let's take a first pass, and maybe we'll get somebody to come in and improve it later." You have that cross-functionality you just didn't have before, which is great.

Somebody on our governance team who's not a developer built out a separation of duties and privileged access management tool. It took some time, but it's fantastic. Before, if I had had somebody who's an auditor or something and said, "OK, I need you to build me this tool," they'd have said, "Why are you asking me? Go ask a developer or an engineer. I don't know what you're asking."

Matthew Connor: Yeah, no. I think that's a great example. Somebody who's not a software developer actually fully developing a privileged access management tool is phenomenal. But I can't help but wonder, as we see cars moving in that direction, it will make no sense for a human to ever touch a wheel, because it will be more dangerous. I don't think anybody believes it will be anything other than that at some point in the future. It just makes the most sense. Every sci-fi movie, every technology you look at, it makes perfect sense that it's safer. Humans won't be able to keep up with all the autonomous vehicles on the road. It won't make any sense for people to be in that mix.

So will that same thing apply in so many other areas, where we will see AI, and people will be there for the business side, for the human interactions? And I think you've touched on it a few times, and this is really important: understanding the fundamentals, understanding the theory and how things work. The software engineer won't necessarily be a coder, and it's kind of sad for a lot of good software engineers. Once AI is far superior as a coder, which it is right now, they all become more senior engineers. They all become architects. They all level up, to where their job is that you come up with the ideas and you guide your software engineering AI to do the coding, and you get the results.

Will that apply to all jobs in the not-too-distant future, where the standard of work output is so high and expected to be so fast that the only way to possibly keep up will be leveraging AI properly to do whatever your job is, whether it's finance, accounting, operations, security? You're not going to be able to go through your SSP and understand it, implement it, and check things as quickly as the AI will. So your job has to be, "I'm going to guide the AI, I'm going to tell it to do these things, and I'm going to be the strategist." Is that where we're headed? I know your crystal ball's as good as anybody else's, but how far in the future are we looking, because things are changing so rapidly? How long before that is what jobs look like? Or it's not going to be like that at all, and it's always going to be human in the loop until AGI.

James Hengsterman-Cash: That's a little bit where the autonomous vehicle analogy runs out. We don't right now have adversarial autonomous vehicles on the road. And I think if we did, people would say, "No, I need to know I can see when the system is trying to do a thing." With computer vision, it's like, I can tell that those stickers on the stop sign don't mean it's a speed limit sign. I know it's still a stop sign no matter what they put on there.

We're going to see job roles change, absolutely, but it's the same way that when computing was adopted, you don't still have organizations using pen and paper for the most part to do things like finance. So those roles are going to change. But with any system, and with people, people are part of your defense in depth, and the human brain is one of the most complicated things there is. It far surpasses the complexity of everything we've managed to create. So people are still going to be useful in those roles. I think at some point in the near future we're going to get to a point where maybe you only need a handful of senior developers or senior SOC analysts. Then what happens when they leave? If you haven't cultivated that pipeline of junior SOC analysts all the way up through the operations team, now you're out of senior SOC analysts. And yes, maybe you have a model that can very accurately predict those types of things, but you don't have any expertise in it, and at that point you have to count on a model to make this continuous improvement.

You don't have people saying, "Oh, I come from..." You've probably seen in security that people have all sorts of backgrounds. Music majors, the medical field, legal. You have all these different backgrounds where people come in and say, "There's actually a much more elegant way to solve this problem because of this background I have or this deep understanding of the system." If I had a system saying, "If you have any questions about the SSP, just type it in and it'll give you the answer," then I don't have an understanding of the system, from some level. Even if the system can do that for convenience, I still need to have that level of understanding.

So, crystal ball and all that, we're definitely getting into it, and we've already seen it. This is a pretty drastic shift, folks. Jobs are changing, the cost-benefit analysis, tokenomics, all of that is coming into effect. But it's like anything: if you adopt it the wrong way, you're going to run into new and exciting problems that have yet to be discovered, because we are in a new space. So I would love for these to be adopted more in tandem with people, so that instead of saying this AI system can replace this person, it's that this person can have 10X the quality of their work, where they've saved 90% of their time and can go off and do other things, like you said, at the more strategic level.

But yeah, I don't know. Maybe we do get to a point in the next 5, 10, 50 years where no level of expertise could exceed these models. I don't know. I think that's a more fundamental shift that we would really have to account for, because what happens when, as a security practitioner, you say, "Oh, I think it should be like this," and then you ask the model and it's 100%? That's not the case now. I can ask it something and it's like, "Well, you're almost right, but not quite." What happens when we get to the place where the best practitioners go to ask a question and the model's always better? I don't know. I don't see that. I haven't seen these models get to that point yet. I know there's been lots of sales and marketing saying that we're getting there, but I'd say, prove it first. Once we do, it's our responsibility as security practitioners and as technologists to take that and make things better with it, to incorporate it into these systems and improve what we're delivering, or what the mission is. It's interesting times we live in, for sure.

Matthew Connor: Couldn't agree more, James. I think that is well said. I can't thank you enough for coming on today. This has been an absolute blast. I think we covered a lot of ground, a lot of really fun and interesting stuff. But before we go, can you tell everybody where they can find out more about you and more about Unison?

James Hengsterman-Cash: Sure. If you are a GovCon, or in the DoD, or a federal agency, and you aren't already working with us, you can go to unisonglobal.com or you can reach out to us. We've got all sorts of stuff there. My name is fairly distinctive, so if you just search James Hengsterman-Cash on LinkedIn, you're welcome to connect with me there. I also teach as part of Duke's executive AI and security courses. If you are interested in AI and security and you are a leader, we have some coming up in South America, I think Mexico City, Panama, the Dominican Republic, and a couple of other places. It happens every year, so if you're looking to get up to speed on these things, that is a great place to look as well.

Matthew Connor: Fantastic, James. Thanks again, and until next time.

James Hengsterman-Cash: Thanks so much. Have a good one.

Read On

CMMC, M&A Integration, and AI Upstream Defense with Bobby Barts - Ep 228

CMMC, M&A Integration, and AI Upstream Defense with Bobby Barts - Ep 228

Bobby Barts is the CIO of VT Group, a government contractor serving the defense and intelligence...

Read more
Deepfakes, Demos, and the Real Cost of a False Sense of Security with Chris Pacifico - Ep 216

Deepfakes, Demos, and the Real Cost of a False Sense of Security with Chris Pacifico - Ep 216

Chris Pacifico is the Director of IT at Rehab Medical, a durable medical equipment provider that...

Read more
No Longer Exploratory: Building AI Governance for K12 with Desmond Grant - Ep 223

No Longer Exploratory: Building AI Governance for K12 with Desmond Grant - Ep 223

Desmond Grant is the CIO of Littleton Public Schools, a high-performing school district located...

Read more