Why Security Policy Fundamentals Matter Again in the AI Era
Security policy fundamentals are back in the spotlight as AI changes the economics of cybersecurity. Alan Shimel welcomes back Dan Rheault, Director of Product Management at FireMon. Furthermore, Dan shares how a sociology degree and a pen testing start shaped his view of security.
From firewall monitoring to security policy
FireMon began 26 years ago as a firewall monitoring tool. In addition, security policy now lives across public cloud, SDN, Kubernetes and on-prem data centers. Consequently, FireMon manages those policies consistently across every part of the network.
The cost of chasing point solutions
Dan says a decade of shiny point solutions has pulled teams away from the basics. Meanwhile, FireMon data shows 60 percent of customer policies fail their own internal controls. As a result, about 20 percent of access is redundant and many rules sit unused.
Temporary access often becomes permanent, and workload migrations add even more holes. Therefore, Dan describes most enterprise networks as Swiss cheese. Furthermore, AI tools like Mythos make reconnaissance and exploit development far faster. In the first two weeks of Mythos, more zero days were disclosed than in the prior two years.
Getting back to security policy fundamentals
The answer is the work teams should have done all along. In addition, every access rule needs a lifecycle and must be justified over time. Consequently, least privilege remains a core tenet of any zero trust framework. Teams must also plan for a safer future state.
Customers are also using application aware policies to control which AI models can talk to each other. Meanwhile, FireMon is preparing an MCP server and agents built into its own product. As a result, customers who do not want to build their own tools will still be covered.
Explore more cybersecurity coverage and the latest Techstrong TV interviews on security policy fundamentals.
For more information please visit firemon.com
Transcript
Hey everyone, welcome back here to Techstrong TV. My next guest is my friend Dan Roe, Director of Product Management over at Firemon. Of course, Firemon's a company we've, I think ever since I started, well, even before I started Security Boulevard, I worked with Firemon Jody Brazell, even back in the days when Gary Fish was there.
And been following Firemon all these years. Dan, it's great to have you back on. I hope all is well with you.
Yeah, all is great, Alan. Thanks for having me. So Dan, before we jump into Firemon and then our topic of discussion today, I wanted to spend a little bit of time talking about you.
Give people a sense of your journey to becoming Director of Product Management here. Yeah. So I started in cybersecurity within penetration testing at a company called Core Security Technologies.
I worked with the professional services team. We would deliver penetration testing at a time when people had a hard time disambiguating between vulnerability scanning and pen testing. Mm-hmm.
So worked with some really top-notch smart people. Definitely not where my degree was, but where I ended up professionally. So after that, a fintech company, we exited that, and then I worked at Tufin for about six years, where I worked in product marketing and then product management on the innovation side, bringing new things to market, solving some new complex problem spaces.
Had a three-year stint with a couple buddies I had at Tufin, at a startup, basically a CASB provider, where I got to get pretty deep into the incident response side of things with enterprise organizations. And after we exited that, the next logical step was just boomerang back into SPM, although that's not necessarily all that we're doing at Firemon today, but that is- Absolutely ... obviously part of the focal area I work within.
So but it does beg the question, what was your degree in? Sociology. Oh, there you go.
A liberal arts major. Excellent for social engineering. You know what?
I'm gonna tell you, so government politics major here, history minor, went on to law school. But I still truly do believe that getting a good solid liberal arts kind of education where you have sociology, psychology, history, it makes you a well-rounded person, able, I think, to be more versatile, and deal with changing conditions, right? And so while I know a lot of people say, "If you're gonna go to college, make sure you're gonna do something, you've got a degree that'll pay," something technical, almost like a return to vocational schools.
There is something to be said for a good sociology degree or psychology degree- Uh-huh ... or what have you. I think particularly in cybersecurity, right?
Yeah. I mean, granted it's a tech discipline, but it's so multifaceted, and then you have to think about how you speak that in the context of business. Sure.
Understanding the stakeholders, understanding what the priorities, the outcomes, and what things need to change because not every problem is a technical problem. Half the time it's political or cultural. You're right.
I speak to so many kids coming out of school. They have cyber degrees now. They didn't have that when I was younger.
But they have a hard time getting started in this business, right? Oh, yeah. Though they have that technical training in school, it doesn't translate.
Anyway, enough patting ourselves on the back about wise choices we made as undergrads. Let's talk a little bit about Firemon. You hit it.
There was a time where Firemon and frankly, Tufin, the company you were with earlier, I called them firewall rule managers, right? It was really good if you had more than three, four, five firewalls and you wanted to have standardized policies, process, rule in place and you needed a Tufin or a Firemon to help with that. Went to policy rules management, grew beyond firewalls.
But now, especially in the case of Firemon, it's so much more, right? There's a lot more to it. Dan, for people out there who maybe still think of Firemon as just firewall rule management, tell them about Firemon today.
Yeah. Well, I mean, it's really uplifted to security policy, right? And I get it, 26-year-old company, even the name Firemon was Firewall Monitoring Tool, right?
Sure. So we kind of look at that ourselves, but at the time, very appropriate. But security policies themselves don't just exist on firewalls.
There are all sorts of policy enforcement constructs out there. So when you think about the evolution of the network, sure, firewalls were probably the starting point, but that's fundamentally changed, right? We've gone through layers of technical innovation in the networking world, SDN, public cloud, right, Kubernetes, all these things require security policies.
And one of the main reasons that we've maintained relevance over 26 years, right, which is kind of crazy in the technology space, is that the problem has persisted consistently as we've changed the networks. Because it's a time-honored tradition where we go invest in a new solution, new platform, we extend our network, we bring in new technologies, and what happens in those situations when that occurs, is you have new teams doing new things. And so I always think back about the public cloud.
Do you remember all those, it was all the headlines, there was a pwned EC2 instance or something like that. " And the answer was, well, security policy wasn't really part of the consideration. We were just establishing infrastructure to enable connectivity.
So the answer to that is to put in a firewall, start managing all these security policies consistently alongside one another. And so that is how our organization has evolved too, right? It's no longer just firewalls, it's no longer the identity policies, but it's those policies in the context of the rest of the network, whether that is public cloud, in which case it's pretty much all the public clouds, SDN providers, which we're seeing some boomeranging back and forth now.
I have customer calls where someone's going full public cloud providers. I have other customers that are going full SDN, and I have customers now that are still investing, growing out their on-prem data centers and bare metal servers. So there is all sorts of interesting changes.
The thing is, in these changes, the consistent adherence application management of security policy has to be consistent. Yeah. Agreed.
And I would even say, look, with what we're seeing going on in AI and these kinds of things, going back to on-prem or third-party data centers and bare metal is a thing for sure, right? It's growing, not sustaining or maintaining. It's probably growing.
Not that the cloud's going away. I'm not out here, I'm not one of these cloud doomsayers. But we are seeing a return, I think, to a little bit more control on-prem.
The whole sovereignty issue around it and everything else, I think plays into it. Hey, Dan, I want to do, I mentioned AI, right? My last interview we were talking about post-Mitos and what it means for vulnerability management.
But AI is really having sort of a blast radius throughout the cyber silos, if you will. And what I find, not ironic, but some things never go out of style. Security in depth, right?
I've been talking about security in depth now for, I don't know, 27 years, 30 years. But here we are talking about security in depth again, aren't we? Yeah.
It's defense in depth, but it's also trying to wrangle the complexity. Because for as long as I've been in this industry, complexity has always been the enemy of security. And then think about the complexity that we've created within enterprise environments, right?
We're talking about the expansion of networks and the technologies and everything else like that. Parallel to that, you've also had the last 10 years of people chasing point solutions to apply to addressing risk. What's been really interesting is that as we've introduced more technologies across all of our network ecosystem, is that the pursuit of these point play solutions has actually led to the neglect of those fundamentals.
Yes, they have. And it's funny, I don't know if I agree with you that complexity is the enemy of security or security is the enemy of complexity. I think security by obfuscation was in some ways part of that complexity.
It became so complex, it became too hard for people to do something. But The fact that we would lose sight of fundamentals, of that defense in depth kind of way of looking at things, of doing the block and tackle, just normal security things because we're so busy chasing the latest, greatest exotic. It's an old story in some ways, right?
You can't blame AI for this. We've had shiny trinket syndrome in the security business for as long as there's been a business, and nothing changes in that regard. No, it doesn't.
And then, the interesting byproduct of this, when we've started pursuing some of these new solutions at a point in time, is it's distracted from what we really needed to be doing. Right? So when we last connected at Black Hat, that's one of the few times I've left where I felt like I actually have a good read on what everyone needs to do now.
Because even as we work with our thousand-plus enterprise customers, some of the analytics we pull and share and anonymize with them have left a really compelling narrative of what the actual current problem space is. Because when we've been distracted by chasing these things, these point solutions, we've left the fundamentals behind. And the result of that, and all these changes across the network, is that every enterprise out there has far more aggregate access than they ever really need.
And so even at the highest possible level, when our customers are assessing their security policies, their actual network connectivity, trying to figure out what is secure, what's not secure, what's a vulnerable ingress point, what's unused, 60% of their policies are failing their own internal control mandates, which means that it constitutes risk to the business. Then parallel to that, you have about 20% of that access, which is redundant. And even within that, you have a gross amount of unused rules.
All of these are indicators of the fact that we've been kind of ignoring our best practices, and it's a normal result from how we've all operated. So like an application comes online, we're going to write new firewall policies. Well, actually, we don't really want to allow that service, so we'll do it temporarily, and then we'll disable it later on.
But later on is still now and we haven't done anything. And then you think about all the complexity of migrating workloads, introducing new network environments, and now every enterprise network out there is basically Swiss cheese. And the real problem in the context of AI and Mythos is that everything that was already vulnerable to begin with now has the ability to be exploitable.
Right? Reconnaissance is far more efficient than it used to be. Exploitation development is happening way faster.
The first two weeks of Mythos, we had more zero-day vulnerabilities disclosed than we had in the last two years combined. That's nuts. Couple that with everything being wide open on the network side, AI has fundamentally challenged the economics of cybersecurity.
Agree. I don't dispute it or disagree with you at all. The question is, okay, so what?
What do we do? What's the answer here? Do we all go back and take security fundamentals 101?
Do we hope Obi-Wan, you're our last best hope that somehow the Force helps us? What do we have to do here? Yeah.
We need to find the perfect solution. But it's kind of funny because if you look at security and what we need to do, it's the stuff we should've been doing the whole time. All this unnecessary access environments is something that can be dispositioned effectively, because you have to attach a lifecycle to it, right?
We have to ensure that every beginning has an end. That is the tried and true adage in security, at least on the networking side. Access, when it's created, has to be continuously justified over time.
And we've just really ignored the whole justification, unless there was some sort of penalty associated based upon an auditor for a third-party service, like KCIDSS. So I think part of it is we actually need to do the things that we know that we need to do, and least access privilege is a core tenet of any zero trust framework. The other aspect of that is move forward state, though.
And we already have a lot of technologies that are super helpful to enable this. So in the context of AI, it's not just AI as a threat, but virtually, I'd say pretty much all of our customers are either assessing or implementing AI internally within their company to produce more software, more solutions, more deliverable services, which is excellent. But now there's also a little bit of a conflict here because all of these things are now able to communicate over this overly permissive access.
So now there's a lot of interesting solutions I'm seeing our customers employ, where they're using the application-aware security policy capabilities of our integration partners, where they can actually start to define the permissible policies, what can connect to what, and then overlay that with a control assessment. So they know that if AI is operating their environment, if there's something that would violate which models can communicate to the other ones based on that kind of abstraction security policy, that's been helpful to at least make sure that when we do have policies in place today, that they're not permitting unauthorized access between AI models. And that's just one quick example.
But move forward state, you think about how quickly information can transfer and how quickly that information can be shared. That ends up being a pretty critical focal area for pretty much every enterprise customer we have. Excellent.
Dan, we're almost out of time. com? com has it all.
Absolutely. Anything else new on the Firemon side? Oh, yeah.
We've got some pretty interesting stuff coming down the way. A little bit of sneak peek. Obviously, in the context of AI, the way that we have always been positioned, at least in terms of how our customers look at us, is kind of that source of truth.
I think that's pretty critically important because good data in means good outputs on the other side. And then you think about the layered logical consequences of things building up over time. That's been pretty exciting.
So at Black Hat, we shared some information about an upcoming MCP server we'll be releasing, as well as some of the implementation of agents within our own product. So if customers don't want to build it themselves, we'll still have them covered with our own Jeptic framework. Cool.
All right. Dan, come back and see us soon. Yeah, absolutely.
I'll appreciate it. Always. Dan Rho, Director of Product Management at Firemon here on Texteron TV.
We're going to take a break. We'll be back.