Minutes to Exploit: AI and the Modern Threat Landscape

Cole French:

The threat landscape isn't just evolving, it's accelerating. What once took months to weaponize now emerges in minutes as AI automates discovery, analysis, and exploitation at a pace security teams have never had to confront. In today's episode, we unpack how AI is reshaping vulnerability timelines, transforming both offensive and defensive security, and forcing organizations to rethink what secure before release really means.

Welcome to the Cyber Compliance & Beyond Podcast, a Kratos podcast that brings clarity to compliance, helping you leverage compliance as a tool to drive your business's ability to compete in any market. I'm your host, Cole French. Kratos is a leading cybersecurity compliance advisory and assessment organization, providing services to both government and commercial clients across varying sectors, including defense, space, satellite, financial services, and healthcare.

Now, let's get to today's episode and help you move cybersecurity forward. In today's episode, we explore how the threat landscape has fundamentally shifted in an AI-driven world where vulnerabilities aren't emerging over months or weeks anymore. They're identified, weaponized, and exploited in minutes. We begin with one of the core challenges organizations face, securing code in an environment where AI engines can rapidly analyze logic, uncover weaknesses, and probe applications faster than traditional human-led testing ever could. What used to be predictable timelines for exploit development has collapsed, accelerating risk across every part of the software lifecycle. From there, we dig into how AI-powered testing is transforming defensive strategy. Modern tools can analyze mobile apps, APIs, and backend logic at scale, surfacing flaws that aren't traditional CVEs, but our subtle architectural gaps an attacker could exploit. We look at how continuous AI-driven pen testing, automated logic reviews, and early stage code scanning allow organizations to tighten security left of release, reducing reliance on long grace periods and preventing vulnerabilities from ever making it into production.

We then examine why historical approaches to security, manual pen tests, signature-based scanning, and periodic assessments can't keep pace with machine speed threats. Alert fatigue, incomplete visibility, and reactive processes create blind spots attackers exploit. By feeding AI-enhanced analysis into these tools, organizations gain higher fidelity insight, reduce noise, and shift their efforts toward addressing the nuanced attacks humans are uniquely capable of detecting. Finally, we look ahead at the new frontier of AI-driven defense, automated identification of risky APIs, deeper analysis of logging gaps and guardrails that prevent AI systems from introducing or amplifying vulnerabilities as they assist in development. We break down why organizations must be intentional with how AI is used across their environments from code pipelines to compliance workflows, and why combining machine speed analysis with human judgment is essential as adversaries increasingly leverage AI to probe systems faster than ever before.

Joining me on today's episode is Matt Stern, CSO of Hypori. Matt is an experienced cybersecurity executive leader in both the public and private sectors. Matt has led professional services from a premier cyber threat intelligence company and the United States Computer Emergency Readiness Team. He was also the program director for system engineering, design, and deployment of the National Cyber Protection System and the deputy CIO for the largest-ever deployed military communication system supporting 150,000 Operation Iraqi Freedom II soldiers. Matt is a retired and decorated 22-year US Army combat veteran whose service culminated in command of the Army Computer Emergency Response Team. We hope you enjoy this episode.

Well, Matt, I really appreciate you joining us again here on the Cyber Compliance & Beyond Podcast. Today, we're going to focus our conversation on the threat landscape, and we're going to talk about that generally. And I think hopefully, as everyone knows, AI is out there and everywhere these days, so get into some of the specifics around how AI is impacting the threat landscape. But if you want to just start us off by just talking about the threat landscape that's out there, and if you want to go back in time, talk about the history of it as well, get us to where we are today is the goal from a threat landscape perspective, and then we'll bring AI into that conversation as well.

Matt Stern:

Sure. We were joking earlier, but if we go back to the days of punch cards and punch card readers, vulnerability is really hard to do in that scenario. And obviously it's evolved over time, starting with just normal vulnerabilities in code, and then antivirus came out and then the threats started moving to different things, different ways of getting in, using social engineering, phishing, you name it, and then getting after browsers, moving away from operating systems because they started tightening up, and then the threat continues to evolve. And now what we saw before the advent of AI, especially everybody talks about Mythos, the big scary thing, but it is kind of scary because you're talking about a time when it took months to get proof of concept code out, to get it out there into the wild, and then people would play with that proof of concept code and then it would go dark for a while and then all of a sudden you'd start seeing it in different use cases and the exploits would start coming out.

And that was a timeline that you could almost predict when you would see the first exploit happen with that proof of concept code. So that break was maybe six months. And then obviously competing, different techniques, different technologies started closing that gap, bad guys get better. But with AI, you're now talking about going from months, weeks, to minutes, seconds, and something gets out there and it's not even waiting for proof of concept code to be built, it's just the AI working in the background and discovering vulnerabilities, figuring out logical flaws in code, and it's just become a different world today than it was even six months ago from the terms of detection and protection.

In fact, I was reading some stuff from Jen Easterly a while ago and we actually, Jen and I commanded at the same time in the army and different roles, different responsibilities, but about the same timeframe. So not to date her, I don't want to make her look bad in that perspective or make her feel as old as I am, but the point of that is she was talking about moving code development and code security left of release and getting much better at that. And that's something we've adopted and gone after because we can't wait for ... Once you release the code, you don't know what's going to happen. So you got to make it as tight as you can before release because you don't have time after it's released. It's kind of game over. I think now the emphasis is moving way left of release versus right of release and detection and that end of the spectrum just is important, but it's not as important as trying to shore up your defenses before you even make it production-worthy. So that's my take on it today.

Cole French:

So to that end, what do you guys do? I think that's a good practice, moving it as far left to release as possible. What are you guys doing differently? Are you doing anything differently or is it just you're taking a longer runway, a longer approach? Talk a little bit about how you guys are doing that differently.

Matt Stern:

Interesting. I think it's not a longer approach. We're doing a lot of the same things that we were, but we are absolutely, I [inaudible 00:08:05] how to say this, but death on anything that goes before release. So if we believe this is going to introduce a vulnerability, even a minor one before release, where there was kind of grace period, you have the NIST standard, 180 days after release to fix a vulnerability if you catch it. We're not playing with that anymore. We're trying to make it as tight as possible. So more pen tests before release, more vulnerability scanning, more code scanning, more logical scans, looking at the code from not necessarily what's known vulnerabilities, but, hey, can a threat take advantage of this, not as a vulnerability, it's just the way the code is built or taking a different look at how our overarching security posture is and obviously taking advantage of the AI tools that are being built inside of our different vendors that we use.

But certainly we've really upped our game on pen tests and using AI in those pen tests, and we want to get to the point where we're just continuously running AI pen tests and those logical reviews of our code before it's released. Anything that we can do to shore up our security before it goes out. And I think going through the different assessments, FedRAMP, even the CMMC assessment we just went through, those help us identify potential pitfalls. Even though it's a compliance review, and I know I get into an argument with some folks about this, but compliance and security don't necessarily jive. You can be compliant, not secure, and secure, not compliant. I mean, there are ways to look at that, but certainly in the reviews we've gone through with a certain company I won't name, that we've absolutely identified some things that we need to tighten up.

A big one for us was what we're doing with logging. Logging for us has been a long pull on the tent for a long time and we're getting better at it, but we're also finding ways we can even improve on that and identify potential issues in our log files that may not be indicative of security, but lead to a security event. I mean, I think everybody is doing this. What are the different ways you can look at the problem to identify issues, events or whatever?

Cole French:

Absolutely. I think you brought up a good point when we talk about AI and just that I think the focus most of the time, most of the conversations are what AI is doing to create more vulnerabilities and wreak havoc. But there's also the other side of it where we can use AI as a defensive mechanism and as a tool to prevent some of these things. So you mentioned the pen tests using AI. So is that something you're able to do internally and on your own time or do you work with outside folks who leverage tools that leverage AI? Or just talk a little bit about how you're using AI in a defensive capacity.

Matt Stern:

I think it's both. Right now, we have some tools that we're using specifically that are doing every time we do a release on our client app, it goes through and uses AI to develop or to test the system, and that's all automated. We don't touch it. And then we use a tool called NowSecure, and NowSecure also builds in some more AI that's doing the logical questioning. Okay, if this, then could I exploit? Or could this be vulnerable? So it's not necessarily a CVE, it's just saying, "Hey, here's some other things that could be gaps in your security architecture or gaps in your logic, your code logic or whatever." Those I think are becoming more and more useful that it's just not about vulnerabilities anymore. It's like, "What else are we looking at? How else can we shore this up? How else can we make this more secure?"

APIs are great. What are APIs doing in the background that you don't see? So AI is a perfect thing to be able to get in in the middle of that and determine what's exposed, what's unnecessary. Are you running a bunch of APIs that you don't know about that are doing arbitrary things that you're like, "Why is that even enabled? I'm not using that service." So I think those are great points of running AI. And then when we've leveraged different companies for different assessments, they're using AI, we see it in their pen test, we see it in their ... Because they have the same issue. Let's use AI to do the heavy ... I don't know if it's heavy lifting, if that's the right term, but let's use AI to get after the majority of the things so we can concentrate on some very sneaky attacks or the customer said they were worried about X, so let's dig into that, let AI do the rest of this, and even leverage AI to help with that certain thing. And maybe what we're using AI for is to do those mundane tasks so we can concentrate on the ones that maybe take a little bit more human analysis.

Agentic AI obviously is changing the game. Generative AI is very easy at ... We're looking at how do you go through, especially with compliance, how do you go through all your documentation and make sure that you're saying what you're actually doing or you're saying, are you documenting the right thing? So we're using AI in a lot of different ways from a compliance and security point of view. And I think our vendors that support us are doing the same thing to concentrate on the things that people do better than computers or computer logic does. And I think that's really important, especially since there's not a lot of guys that are walking the street right now that you can pull in and say, "Hey, I need you to test this code." I mean, we're all fighting after the same resources. All the security industries, we're all looking at the same people, trying to entice them to come over or to join your team, and you're competing against everybody else who's in the same boat.

And now the AI vacuum has come in and people who really want to do something new and different are jumping onto the AI bus and they're going to do work for companies that have AI in the title. Ourselves, Hypori AI. It could be RadOS AI. I mean, it's kind of getting that way. Everything's getting to the point where we just put AI on it, say we got AI now.

Cole French:

It's like the trademark that comes after instead of that, so we just put AI there. I think something you said actually stuck out to me or maybe a connection I made, is the AI is forcing us to look beyond CVEs. So historically it's been, "Oh, I got to reduce the CVEs and patch vulnerabilities," all that kind of stuff. But what AI is allowing us to do is look way far beyond CVEs and into the logging stuff that you mentioned. It just brought to my mind, if I can have AI look at all the logs in my environment, I'm sure it would highlight a whole bunch of things that maybe there's not a CVE for that, but it does represent a vulnerability or at least makes me ask the question, why is something configured that way or why am I seeing that behavior in my environment? And that could lead us to identifying something that we definitely don't want to be present in our environment.

Matt Stern:

I think from that perspective, Cole, you bring up a great point. I'm going to go on Wayback Machine for a second. When I was commanding Army CERT way back a really long time ago, I remember the Army had seven vulnerability assessment teams and everybody was jumping on that bandwagon. We had the original, but there was a bunch of others coming up, and I remember the Army's IG, Inspector General, was going to build a vulnerability assessment unit. I remember sitting down with the colonel that was responsible for building this out, and I looked at him, I said, "Sir, why are you doing this? Because we got a lot of people that are searching for vulnerabilities." And he was like, "Well, because we want to be able to see if there's systemic problems." I said, "Well, that's great if you're looking at systemic reasons, but if you're just going out there to say, 'Hey, your system has 10,000 vulnerabilities,' and not digging into why that system had 10,000 vulnerabilities, then we're already doing that. And in fact, I can do a vulnerability assessment of any system in the Army sitting in this chair."

And he looked at me and he goes, "What do you mean?" I said, "Okay, name a system." And he named a system and I said, "It's vulnerable. Okay, next one." He just looked at me and I go, "Sir, it's vulnerable. By definition, it's out there, it's going to have vulnerabilities. They can be exploited. What are we doing to get after the systemic problems that build the vulnerabilities? What are we doing outside of that?" And I've never been a fan of the fixation on vulnerabilities because I'm a fan of exploitable vulnerabilities, not that count of I got 20,000 vulnerabilities in my network. Okay, what we do? How many of those are exposed? How many can somebody actually do something with? So exposed vulnerabilities, that's a big deal, and I think that is something.

But then why did the Department of War create STIGs, the security template implementation guidelines? And it was because, well, vulnerabilities are one thing. Configurations, to your point earlier, configurations are a whole nother thing. If you leave password, "password," that's not a vulnerability, that's stupidity, and that's a configuration thing that we've got to fix, and you got to make sure that you're running configuration checks.

Okay, so is there other logic in your system that can be exploited that isn't a known vulnerability, can't be expressed as a vulnerability, maybe it's not a configuration, but it can be exploited. Humans, obviously, we are, by design, people that want to trust people, and we probably give up too much information and everything else. I think personally, that's an issue that AI is just highlighting, is it's not just about vulnerabilities anymore. Vulnerabilities are a thing, yes. Are they exposed vulnerabilities? That's a great thing for AI to be able to pull through and say, "Okay, based on your architecture, everything else, we've looked and said, 'If the bad guy gets you right here, you're kind of done.'" Old military terminology, where's your decisive point? Where's the place where you lose if he gets that nugget, that gold nugget? Is it in your cryptology? Is it in your identity and access management? Where is it in your infrastructure? What's your golden goose?

And I think it isn't always going to be a vulnerability. It could be a configuration, it could be some part of your code that would become a vulnerability if you figured it out, but it could be something else that's entirely different. And I think we're just getting into what does that look like and how is AI going to expose it or find it? I think that it's an interesting time because I think up until the point of AI, to be truthful, security's getting pretty boring. It's whack-a-mole. It's do these things, do it right. You got a good chance that you're going to be okay. But we all know in the security game, what if the bad guy just drives a Mack truck through your front door and there's nothing you're going to be able to do to stop that? He's going to get in and you had a bad day, he had a good day. And that's the game we play. It's a game of odds, really.

I think that's where we are today is we've changed the game, and I think for me as a cybersecurity professional, long time, been doing this for a minute, it's kind of exciting because it's different again, and they've changed the rules, the game has changed, and it's maybe if you decided baseball would have some notion of physical contact between players, so maybe a combination of ... Baseball today, to me, it's pretty boring. I loved playing baseball as a kid, but I don't like watching it. I love watching football because, well, people are getting mashed, and it's kind of fun to watch that. And maybe if you put a physical element into baseball like you have in football or rugby or whatever, not soccer because I know that soccer is much more dramatic than ... You have to have theatrics.

Cole French:

Yes, yes. And soccer is very much, soccer and basketball both have the theatrical, I feel like, the theatrical components.

Matt Stern:

Not quite WWE-worthy, but there's a lot of soccer theatrics going on, and not to belittle the World Cup or anything like that, but it's not my sport of choice. But my point is, I'm excited to be part of the cybersecurity world today because AI is really interesting, and what it's affording us and what it's doing to change the game is just, this is really interesting times. It really is.

Cole French:

And I think something you pull the thread a little bit on that is the whack-a-mole thing. So that is exactly what it's like from an operations perspective, and you can run a good security program, and I've worked in the past running vulnerability management programs, and those are great. Every organization should have them. You should patch vulnerabilities, all that. We're not saying don't do those things. But what I always said, what I always have told people, is that's just a small component.

And we've talked on this podcast many times about assessing risk and performing risk assessments, and you kind of touched a little bit on that where, "Yeah, that's great. I patched all my vulnerabilities, but do I actually understand why I patched those vulnerabilities or are those vulnerabilities exploitable or are they on public-facing systems?" It gets into much more than just, "Oh, I have only 10 CVEs in my environment right now." I think we look at those very surface-level measurable things and we're like, "Yeah, I'm good," but we don't look at, "Oh, I patched everything except for that one thing that's on a publicly facing system that is exceptionally vulnerable."

So I think, to your point, it is exciting because AI brings something to the table that I think from our ability as humans to comprehend is very difficult with what you just mentioned as well, which was there's a strain on the human capacity to do this to begin with, but then when you extrapolate it out to an entire industry and many different contexts and all that stuff, there's just no way that we as people can keep up with the risks and identifying the risks and all that stuff. So we can bring AI into this, not just from a technical perspective, but also from an organizational thought process perspective, and it can illuminate things that we don't even think about, I think. Yeah, we can provide the inputs and help drive it and shape it, but it's going to bring things to the surface that we're probably not even thinking about. And to your point, that is really exciting.

Matt Stern:

Yeah, it's interesting, and maybe it's just because I've been doing this for a while, I have a pretty broad experience of being involved in cybersecurity. So for me, a lot of times when I'm looking at logic or data that's coming to me and I can look at it and say, "Okay, that's a problem," because I've seen it before maybe. And it goes back to, I remember a few years ago, we have a product security council when we meet, we talked about prioritizing, because we only have so many resources, what we're going to go after, what we're going to fix, what can be ... Based on risk. To your point, it is risk-based. Okay, if we're going after, if we've got a hundred things to do, we can't do them all at once. At some point in time, we got to figure out what's the most important and take them on from that perspective.

And I remember I was going through the list of things that we weren't going to do. We just said, "They're trivial, we're not going to do it." And one of the things was an info-only CVE on cryptological element on a component of our infrastructure that is critical to our security. It's kind of like a firewall, critical to your security, and the encryption related to it or the cryptographic elements related to it had a vulnerability in it. And I'm like, "And it's exposed." And I was like, "Wait, what? This, on my scale of one to 10 on CVEs, is a 12, not a one." Because arbitrarily, if you don't do risk-adjusted scoring, this is another thing on vulnerability management, if you don't do risk-adjusted scoring based on your knowledge of your architecture, exposure, everything else, you might as well not be doing it, because you can't get after everything, you can't fix everything. You've got to know your architecture. This is also where AI can help. Knowing your architecture and understanding where you can put those toggles in place to say, "This is a really important component of architecture, so any vulnerabilities related to that I care about immediately because it's exposed, whatever, it's critical, it's exposed, whatever."

But this server that's sitting way back here that is written in a language that it doesn't, whatever, I'm not even worried about that one because there's only five people in the world that can actually do something in that component. So, I mean, from that perspective, being able to do that risk-adjusted scoring is really important, but it expands out to just not vulnerabilities, it's your whole architecture. It's looking at every component of it individually and then as a whole, and then being able to have ... And I think it's one of the things that we've done really well, is being able to gather the developers, the operations guys, and the security guys, and we sit in a room and we can debate where our focus is going to be. And I think, once again, AI can just allow that to bubble things up to the surface way faster.

And what we're also noticing is I don't necessarily have to have us sitting in a room to do that. We can all look at the same data, we can all go to the same data source, and if it says, "This is number one," we can quickly go, "Yeah, I agree," and move on. We don't have to have a big meeting where we sit in a room, waste everybody's time, and then come up to the same conclusion. So I think the modern vulnerability management, security councils, whatever you want to call it, can take advantage of those things, and my advice would be, you don't have to have a meeting. You can just have access to the data and present your data in a way that everybody can go, "Yeah, I get it. It makes sense. Let's move on." Once again, I think that's a mature organization's way to look at just security across the board, not just vulnerabilities, but how are you looking at, going back to the original discussion about threats, how are you countering the threat?

And a lot of this goes back to my military days. Before I became a computer geek in the Army, I was an infantry guy. And you always started with the threat. You always started with that assessment. Who's coming after you, how are they coming, what are they going to be focused on, and then what's your best way to defend against that? Of course, the best defense is a good offense, but that's a whole nother topic. But I think that from my mindset of understanding the threat, what I would be interested in going after, what would be my targets, my number one targets on my list, and building my layers of defense around that, I think that helps me a lot in understanding the big picture and not going back to the whack-a-mole, focusing on the many, and really getting after where are we most exposed, how do we defend against that, and how do we layer that defense so that we're not relying on one system, because that's another recipe for failure.

Cole French:

And I think it's important, like you just described, having those filters, I call them, upfront, where it's like, "Okay, I've already defined these five things," or whatever it is. Each organization will be a little bit different, but I've already defined these filters through which I'm going to look at all this stuff that's about to be presented to me, having that as much as you can ahead of time or before you start getting into this, I think is extremely important because going back to the whack-a-mole thing again, organizations that don't do these things particularly well, but let's say there are large organizations, have a lot of assets, a lot of different operating environments and stuff like that, and then let's say you go into a modernization effort and you start bringing a lot of these tools online and it just lights the place up. There's just stuff everywhere.

But if you don't have filters in place, you don't have an understanding of what's most important to least important, where do I really to care about vulnerabilities, you'll see that, just the blinking lights everywhere, and then everybody becomes hyper-focused on, oh my gosh, how do we address this giant threat landscape? When in reality it might not be as bad as it seems. And then if you have that in place beforehand and you're looking at it with those filters in mind, and that could even be like, "Hey, this is a low, but actually because of the type of system, the example that you just described, maybe it's super important." I think having that and thinking about it beforehand, before getting into these vulnerability management efforts is huge because otherwise, yeah, you'll end up becoming hyper-focused on this massive number and you just keep going after that, you expend all your resources. And I think then you completely lose sight of what's potentially most important and, by virtue of that, what's most vulnerable.

Matt Stern:

Yeah, I think it's challenging. The other challenging aspect to it is back in the day when you sat in your office and you had a network and you connected to the network and you had firewalls and IDSs and you had stuff, today none of that really exists. It happens in the cloud, but on your laptop, because we're probably like you guys, most companies today or a lot of companies today have a large remote workforce. Some companies are totally remote, no infrastructure at all. So every single one of your laptops are bastions. They have to be set up to protect your data, protect ... You don't know what they're connecting to. You have no clue. And I think one of the things that, shameless plug for Hypori and what we do, is this whole philosophy, and I'm really wrapping my mind around this these days, is move the user to the data instead of the data to the user.

Forever, we've always wanted, we never trust the network, we never trust the servers, we never trust where we're storing anything. I mean, PST files, look at that. I mean, we can go on and on about all the different ways we've created technology that allowed us to work remotely, but also there was also a trusting. We didn't trust where the data was. We didn't trust that our data would be there when we needed it. We didn't trust we could share it. Well, today's architectures, 5G, 6G coming, the fiber infrastructure, the speeds that everything's traveling, the ability to share data. I don't know that you necessarily need a copy of data everywhere. Plus you got to worry about data manipulation.

Here's another thing AI is going to be doing. I am concerned because I'm putting out my information operations background and things that I was involved in in the military of what if you manipulate the data? What if you manipulate the AI? What if you get in the middle of that logical stream? What if you go out there ... And so how are we protecting our data, protecting the integrity of our data? In the government, God, forever we've been fighting this thing about identifying the classified tools that classify your data and your data sitting in, it's a classified data, it's sitting on a classified network, and you don't ever want that stuff to get out. Well, why are we moving it in the first place? Why isn't everybody just operating and working off the same, say, Word document? We can all see it. We can all manipulate it. It's because we want to download a copy because we want to be able to make sure we got it in case we need it.

And I think that world is, in a lot of ways, we've got to be more mature, because I think we run our approach to networking like a kid with our candy or toys at Christmas. I don't want to share, I just want my stuff. And if you ask me nicely, I might give you something, but really this is mine and I want to keep it and I want to make sure I keep my hands on it. And that's a very, I think, immature way of thinking about data and thinking about document control and stuff like that. A more mature model is, let's move the users to the data, let them have access, but don't move it ever, because we can control ... I think we have a better chance of controlling access to that data than we do of classifying the data, ensure the data doesn't leak or get out or do something else out there.

And I think AI just is going to explode the crap out of that. I mean, not only you got to worry about the integrity of what that data file is, but you also have to worry about where it is and how fast it can move. So I'm becoming, and it's not just because Hypori, we do that, access to the data, controlling of that. And I think it's more because the logic behind let's be mature of this approach. If you took that model, does it change your devices, your end user devices dramatically? Absolutely. Changes the game. You don't have as much compute power, you don't have as much storage, you don't have to worry about that data moving. What would it change on the end user device if we were just worried about access to data, especially, okay, gaming is different. I mean, there's different scenarios where this wouldn't work, but I bet you for the majority of our workforce and the majority of what we do on a daily basis, your email sits in one place, it just stays there. Things like that, how we communicate, does it really have to move or can it just stay there and I'm just viewing it?

And so I think it would change the security model. It would make it easier to defend in a lot of ways. And I think identity right now is, one of the pluses right now is I think that the identity and access management capabilities that are out there today are pretty good and they're certainly way better than they were 20 years ago or 10 years ago or even five years ago. They were clunky as hell five years ago. Now they're pretty robust, easy to use, integrated with biometrics. I mean, there's a lot of advantages to that that help get after this kind of thinking. So I don't know, I just throw that out there because I think since the game is changing, if we can't affect the AI proliferation, then we should be thinking about how we can change the game from a defensive point of view and look at what we're really doing and what we're really defending and how we're doing that.

Cole French:

And I think to that point, CMMC, which is something that we work a lot with, and that is the prime objective of CMMC is to protect data. So to what you're saying, I think is absolutely right, moving ... And I really like that. Conceptually, that's very easy to understand, move the user to the data. But yeah, you're right. Operationally, we are always thinking about, "Well, how can I get access to that data?" And oftentimes, and this is a funny example, and I guess goes to what we're talking about, that security is kind of this funny thing.

We think of it as people hacking and people doing all this stuff, but it's as simple as we have a collaboration point for where we're working with data and, yeah, somebody pulls it down because they're like, "Well, I don't trust that collaboration platform and all that." So they pull it down onto their local machine and then somebody else who's collaborating on that thing goes, opens that file, and then sees, "Wait a minute, I made a bunch of changes to this file, but those changes aren't reflected in here. This file looks a lot different." And that's because the user who pulled it down to do whatever it is they had to do to it, when they were done modifying it on their local system, then they pushed it back up and overwrote somebody else's work. So you end up with this, there's risk to the data, you lose things, all that kind of stuff.

I think moving users closer to the data, I think there's almost like a cultural shift that has to take place for people to trust ... There's always this inborn, "Well, I mean, yeah, I just don't know if the changes that I make, if somebody's going to overwrite them." So instead they do the thing that almost assures that there's going to be some sort of data integrity issue, which I just think is interesting. But, yeah, as far as in your experience, do you find that that's a struggle, getting users trained in that regard and to think that way?

Matt Stern:

Oh, yeah. I've found that it's funny, when we started our CMMC journey, I said, "We're not going to print anything. We're not going to have printers on our CUI network because I don't want to have to worry." Because it opens up the, "Okay, where do we store it? Now we got to have all this stuff related to printed material." I don't want to deal with it. Screw that. When's the last time you really needed to print something? Really, never. I mean, at least what I'm dealing with in our business, we can email slides to the customer that we're going to go talk to. We don't necessarily have to print it. The government's big on printing. Oh my God, they'll still print everything out. And a lot of that, to your point about the cultural shift, we went from printing, everything was always printed. Everybody printed everything.

I remember when we were working on proposals in our company, we used to have books, binders of printed proposals. And I'm like, "Why did we do that?" Well, that's our absolute copy. And I'm like, "That's a waste of fricking time because we just spent how much time and materials?" And we had to deliver it to the government customer as printed forms. So we had a pristine copy that we kept on a bookshelf, all that print, all those trees we killed. And I'm like, "But we email them a copy too, right?" Well, yeah, but they wanted printed copy mailed and they want ... and then it ... Oh my God, what a fricking nightmare.

And so when we were working towards our CMMC stuff, I'm like, "I don't want to have to do document control. Absolutely. Take it off the ... No printers. We never print CUI, period, end of story. We're not doing that." And everyone in the company was like, and I said, "No, do you guys want to do ... There's a bunch of overhead that comes along with that. We can just eliminate if we just don't print. So it's a configuration. You can't print from any of our stuff." And so I think that was the first culture shift, print everything, because going back to, "I need a copy of it because I want to make sure I have a copy of it." Well, it's the same thing. And then you end up, personal experience, I now save documents and then I save a document and then you get into version control internally. I'll be like, "Where the hell did I put that document? I always save it here if I'm talking about that subject, but it's not there." So now you've got to go into search and figure out where the hell did I store that thing?

And then it ends up it's in SharePoint someplace and you didn't even ... Anyway, so to your point, it's not even really a security thing anymore. It's really a collaboration. Because we can. We can all work on the same document at the same time. You can see my little icons going across the screen when I'm working on a document or I can see somebody else's and I can actually contact them and say, "Hey, I noticed you made that change, but that's not accurate and here's why." And they say, "No, we'll [inaudible 00:41:42]." Whatever. So you can have that discourse, and I think that's very valuable without sending the document back and forth and worrying about did I put somebody on the email? I don't know if anybody's done this that's going to view this, but I know I have done this a couple times in my career where I've sent out an email and put somebody on the CCE or the two line that shouldn't have been there and that's embarrassing as hell.

But, I mean, that also means that data, that document, now is in the hands of somebody that shouldn't have it. And then you ask them nicely, "Hey, can you give me back a document that says whatever?" And so I think it's security in the big picture, the big scheme of if you're protecting, like you brought it up, CUI, for protecting CUI or other sensitive data, it's not just about how bad guys can get in and get to your data. More likely, somebody's going to make a mistake and human error, they're going to make a mistake, they're going to send it out, they're going to do something not intentionally, although we've seen it intentionally where people leak documents or they send a Signal message about invading a country that they probably shouldn't have sent out or something like that. It can happen. People do it. We're human.

And so trying to eliminate that human error, it's tough culturally when we all want to say, "I want my own copy because what if I'm disconnected?" Well, if you're disconnected, are you really functioning? If you can't send out the email, you're not going to really have that discourse. And so if you're disconnected, yeah, you can work on the document, but sometimes I think we don't take those as opportunities for a break. And sometimes I dream about security, I have nightmares about security, I wake up in the middle of the night trying to figure out how I'm going to solve whatever somebody brought up and it just pops in ... I think all of us understand what I'm talking about there. But sometimes I think you just need a break and maybe that plane ride, put your laptop away and watch a movie and take that time to just decompress and whatever. I don't know. That's my thoughts on that.

Cole French:

And I think to add to that, I like the idea that we need to make it as restrictive as possible. So your printer example is a great one because I think we have to get to the place where it's like, this is it and we're not doing this other thing. And it's not that we're not doing it, it's that we're really not doing this. And I think when we create that really hard and firm boundary around things, yeah, maybe we determine at some point in the future that we do need that. We do need to print things. But if you really think about it, and I like what you said, most of the time the things that we talk ourselves into, we leave out the overhead parts. We leave out the stuff that actually creates more work for us when, I like your example, it's like if we just say we're not doing that, then we're just not doing that.

And, yeah, maybe it forces us to come up with a different method, or like you just said about if I want to work while I'm traveling, maybe the answer is because of how we set this up, I'm just not going to work while I'm traveling. And what's the worst thing about that? Maybe that's actually not a problem. Maybe I just do need to just take care of my travels and focus on other things and I'll come back to working on stuff when I'm back in the environment and with access to the systems I need to do the work in the right way and with the most security in mind and all those kinds of things. I think, yeah, I like the concept of we're going to make this as restrictive as possible and we're going to draw hard boundaries around things and we take it from there. And if that means we can't do certain things, then we just can't do them.

Matt Stern:

Yeah, I think sometimes, I have a reputation in my company, some people refer to me as Captain No. As the chief security officer, I'm really not that bad. I used to be, but I realized we have jobs to do, and I always tell my staff, we're here to enable our employees to do their jobs. So enabling means do it in the most secure manner they could possibly do it, but still allow them to do something. It may not be that thing. So for instance, I need to share a document. Okay, I know you maybe wanted to do it this way, but then we're not compliant. We got to worry about all this overhead. We got to do all these other things. Would it be okay if you did it this way instead? Nine times out of 10, yes.

There's the one case where, "No, customer wants printed document." Okay. Then in that case, then all right, we're going to print it from a laptop. We're going to get a printer that we'll keep offline or whatever and lock up in a safe or whatever we have to do, but we'll come up with a way of doing that thing. Or maybe we've got somebody at a government site that can print it on their computer and then I can meet them in the parking lot, grab the document and go. So not a classified document, talking about CUI or whatever. But you get my point, there's always ways to figure out how to get to yes. And security has a reputation of always wanting to get to no, because it makes our lives easier.

In the case of the printer, I used this thing called logic and I just said, "Okay, how many times has anybody here needed to really print something?" I said, "All right, raise your hand." Nobody raised their hand. And I put it out to the whole company. I said, "Hey, if you need to, let me know. We'll figure out a way." And nobody raised their hand. And at that point in time, I was like, okay, consensus is I'm not making an arbitrary decision. I'm looking at the use case and how we actually are moving data with our customers. Majority of the time, if we're moving data to customer, it's going through a safe or it's going through some mechanism where we can control access and they can control access and it makes everybody happy.

Cole French:

So I know we're coming up on top of the next hour and wrapping up the conversation. Was there anything else you wanted to touch on as we close it out?

Matt Stern:

Oh, I mean, we could go on and on, Cole.

Cole French:

Yeah, I'm sure we could.

Matt Stern:

There's just so many things that we could, but I think I like what we've discussed. And certainly this whole idea of using capabilities, once again, shameless plug for Hypori, using capabilities that allow you to gain access to data without moving the data, eliminating things like data loss. It's a big deal in the world of BYOD, bring your own device. So as companies, well, the whole department, the Army, the Air Force is doing it, the Army Mobility Program, the Air Force is, and they're not calling it the BYOD, but in essence, it's allowing folks to use a device that they're comfortable with, that they use every day to access data. And not to do all their work, but I need to check an email, I need to get on this conversation, I need to message somebody.

That quick functionality without exposing the data, without worrying about data loss, without ever jeopardizing the privacy of somebody's system, it's also becoming ... It's the way we work today. People expect to be able to walk around with their phone and get access to the data they need and the information they need and the communication they need to be successful, whether that's home, dealing with teachers, your kids, whatever, or business, your colleagues or with your customers. In any one of those scenarios, sometimes the only time you could reach that person is at 8:00 o'clock at night, and I don't want to have to go back into the office or drag out a government phone or go through all the machinations I have to get data to that person. I just want to get access to the system that I can communicate with them on. And I think what we're seeing is that that's expanding the horizon.

And obviously, well, now we've just introduced a new thing, a personally owned device that nobody controls. That just increases your attack surface out the ... Just explodes it. So the ability to secure that, once again, I don't see a scenario where, once again, moving your employees, your colleagues, your customers to the data versus having to move it around. Look at DocuSign. Look what DocuSign does today. When I get a DocuSign document, I'm not necessarily getting the document. I read the document, I go through it. If I got to make changes, I can make my edits, I can send it back. We can go back and forth. I never really have the document technically. At the end of the whole thing, somebody prints it off or somebody downloads it and they keep it for the historical record. But technically, I don't have to do any of that. It goes back to that, I don't know if I trust DocuSign, but if I did, it could just stay in there. I get access to it. I have all my legal documents up there and they're taking care of that.

I just think that model more and more is going to become prevalent and ability to access it securely is, help shrink the attack surface going all the way back to our discussion about AI till it's manageable, where you can actually worry about how I'm getting access to that data securely and how I'm preventing it from getting out there where it doesn't need to be. And I'll just leave it with that. That's probably my final note on the topic.

Cole French:

Well, Matt, I really appreciate you coming on. It's always a pleasure chatting with you, and I appreciate your perspective. And I really hope our listeners take away that philosophical nugget that you shared with us, which is figure out ways to move your users closer to the data. Don't resist the urge to move the data closer to your users because that is ... I mean, you're going to introduce all kinds of vulnerabilities. You really just summarized it pretty well. But again, just thank you for taking some time out to come on and chat with us today. Really enjoyed it.

Matt Stern:

All right. My pleasure. It's always fun and I look forward to our next discussion, whatever it may be.

Cole French:

Thank you for joining us on the Cyber Compliance & Beyond Podcast. We want to hear from you. What unanswered questions would you like us to tackle? Is there a topic you'd like us to discuss or you just have some feedback for us? Let us know on LinkedIn and Twitter at Kratos Defense or by email at ccbeyond@kratosdefense.com. We hope you'll join us again for our next episode, and until then, keep building security into the fabric of what you do.