PP103: FireMon Brings Clarity to Firewall Rule Chaos (Sponsored)

Hi everybody and welcome to this episode of Packet Protector, the podcast at the intersection

of Networking and Security.

I'm Jennifer J.J. Javush here with Drew Connry Murray and on today's sponsored show we thought

we were talking about firewall policies and network security policy management with

our sponsor Firemonet.

Turns out Drew, we're actually network security policy management really now is transcending

the firewall boundary and we got into quite a bit more stuff today.

Yeah, I mean firewall policies are obviously at the heart of this but Firemon, as we learn

from CEO, Jody, Brazil, is doing a lot more there.

We talk about zero trust, we talk about automation, we talk about streamlining operations,

we talk about automation, of course there's some AI stuff happening as well.

If you have ever wrestled with firewall rules or had to troubleshoot firewall rules at two

in the morning, you're going to want to turn into this one.

Yeah, so we're going to be joined by Firemon's co-founder and CEO, Jody Brazl.

He's been an industry for a long time.

He has quite a few more stories of his own which is how the company got founded and like

we said, it's firewalls and more including some of the other cloud and all the way into

on-prem network boundary where we're talking about like they're actually have full topology

views and visibility into the switch route infrastructure on-prem and the cloud and even with

some of their partners and micro segmentation. So it's going to be a cool conversation.

Jody, welcome to the podcast. Can you just give us the overview of Firemon, what Firemon does?

Yeah, thank you, Drew. Great to be here. Sure. Firemon is the policy control plane for

enterprise firewalls. Over the past three decades, there have been some really amazing

enhancements and innovations in the network security space. You think back, we started with

access control lists and then proxies and a stable inspection firewalls, application-aware

firewalls and today of course we've made firewalls in cloud and even micro segmentation where

the access control is enforced at the workload. These are all amazing improvements but they all

share one common trait and that is the security is only as effective as the policy that they

enforce. If you have a weak policy, you have weak security and that's where Firemon comes in.

We provide the control plane to help operators better manage these really complex technologies.

So make sure the policy doesn't have security gaps that lead to potential security breaches.

Identify any of those security risks in the policy, ensure policy compliance and even

improve operations with automating policy changes to reduce the risk of those changes to speed up

the process and just simply make it easier to manage these policies. Ultimately,

we say that the policy is power and our goal is to put that power in the hands of these security

engineers. It's fantastic for figuring out why that one little weird policy, somebody stuck in

there, who put it in there? When did they put it in there? Why did they put it in there? Because

when you're managing firewalls, and this is one of the many reasons that I got out of the business

of hands-on firewall management many, many years ago, it's one of the things we did was take a

firewall config and then update it, refresh it, replace the firewall or the whole infrastructure,

whatever. But it's that process of going through and figuring out what all of the different

policies are designed to do and whether or not they're supposed to be there and is it just some

artifact of somebody testing something? And I don't think in the absence of something like

Firemon and the environment, I don't think we've ever walked into a place and had an appropriately

configured firewall based on what they thought it was doing. So it's been just such a fantastic

tool to see in action because you can do a lot more with it than you can with the different

vendors, various management platforms that all are varying degrees of a horrible levels of

suckiness. That's exactly right. I don't think I've ever seen a policy that was perfectly

configured and it's not the engineers fault. These are really complex technologies. We're talking

about thousands of rules in a single policy, let alone the hundreds of policies that you're likely

managing and not to take you too far down the way back, machine JHA, but I'll just give you a brief

story that highlights exactly the point you're making. The whole reason Firemon exists goes back to

when I was doing that job of helping organizations deploy firewalls in the environment. And one day

two a.m. I get a phone call that the firewall is down. I'm sure you've heard that a few

hundred times. Easily to, you know, easy to blame the firewall is blocking something that need to be

open. In this case, I drive into the data center. I look at it and it's perfectly healthy. Everything's

working as expected traffic flowing through the firewall, but they're right as I'm sniffing

traffic on both sides of the firewall. I see that the traffic they're concerned about is on one side

not getting through to the other side. And it takes way too long for me to dig through this really

complex policy to realize that an engineer on their team just made an innocent mistake and put

in a rule that said to block that traffic with no logging. So I had no visibility as to why I was

being dropped. It just was being dropped. It takes five seconds to fix, right? Delete the rule,

reinstall the policy and everything's healthy, but it took hours. And in this case, it was literally

costing them millions of dollars a minute as the traffic that was supposed to be going through

the system was billing data and those billing records were being dropped.

So it was just, it was a silly mistake, but one that was causing a severe issue. And it led to

the creation of this product fireman. Was that a resume generating event for somebody?

Let's tell us about it. It was. I remember what, well, not surprising. I was the vendor. And so

I was on the other end of that phone call with 25 VPs, all pointing a finger saying it's your fault.

And actually, the starting point of fireman was to create scripts that said, who did what when

where? So that going forward, I could point the finger at the right person.

Well, I think you've given a good example, but I guess it gets to the larger question of,

why should people care about managing firewall policies? What do I get out of it as a network

or a security practitioner? What does my organization get out of it? Yeah, huge question. I think the

starting point being a security talk, we have to start with security. So the point that JJ made

that she's probably never seen a policy where it didn't have some security gap. And it is just real.

These really complex policies with the thousands of rules and inside each rule is multiple

objects and source and destination. It's really easy to make mistakes. And the whole point of the

firewall is to reduce risk. And those mistakes could open up the network to extreme risks. In way

too many cases, there are rules in these enterprise firewalls that allow any from any with anything,

right? That effectively turn these firewalls into routers. So congratulations on spending millions

of dollars on the latest and greatest technology. But now you've deployed a policy that makes it

just as effective as a five dollar switch at your local bus buy. So that's the reason to care.

It's from an operator's perspective. They're the ones that back to our point, they get blamed,

right? As if it's their fault that we haven't given them the tools to better manage these complex

policies. So our goal at Firemon is to help organizations improve their security operations so

they can improve their security. And for us, that means giving them the tools to find these things.

So the ability to search a policy for anything within milliseconds, type in what you're looking for,

evaluate all of your policies and return, all of the rules that allow access to some critical

servers, an example. You could imagine a threat event or a potential incident that you're

responding to. One of the first things you may want to ask is how do I control isolate that

potential threat so it doesn't spread within my organization? We give them the tools to ask that

question. Access from this threat to what? What's exposed? And we return all of the access paths that

are allowed through your policy. Now you can take action. And then ongoing, you know, Firewalls

aren't static. The business is constantly changing. And so these change requests that come in at a

high velocity require a lot of engineering efforts to understand the change requests. Okay,

this is the request which firewalls are impacted in this change request. What policies are impacted

is a change even necessary or maybe the access is already allowed. And if a change is necessary,

where should I put it? What object should I use? Where in the policy should I create it?

And providing those design tools to help them answer those questions. This is the change request.

This is exactly the change necessary to accomplish that change request. And now automate that process

to reduce the time and energy necessary to do it. But also to make sure that you maintain the security

and compliance goals that you and the organization have set. And when you say that it kind of like

that that workflow with the request sort of embeds the here's what you need to do and where you do

it. Do you mean down to the specific like that brand of firewall? Like, well, does it hook into

that depth such that, you know, if you're at, you know, multivinder, I think organizations are

all over the place of firewall management. You've got, you know, you've got the guy who like fixes

the printers, the computers, manages the firewall. The one, you know, the one person in 50 hats.

And then you've got organizations who, you know, have specific people dedicated to managing

BGP on the firewall or, you know, like, you get super nishy. And then there's everything in between.

So a lot of, you know, the environments we walk into have, you know, they're not just

whatever Cisco just apologize. It's a mishmash of things because they're large. So are you saying,

like, what's the level of handholding or integration that the platform gives to you for the different

vendors? Yeah, down to the specific requirements for each specific vendor. So when a change request

comes in, you're exactly right. It may, it may transit through a parallel to firewall and a,

and a Cisco router that has ACLs through an AWS, a, gateway and security group, right? Any of

those technologies all are in the path of the access being requested. And the recommendations,

and all the way through to the automation of provisioning will define exactly what changes

necessary for that specific technology. So even for example, it may recommend the specific

object to use in the source and destination of this parallel to firewall with an application

that is defined in the parallel to firewall. But of course, the iOS router that is just a access

list won't have an application. So it'll, it'll recommend the port and protocol necessary to allow

that traffic and then all the way down to perhaps the tags that should be used in the, in the rule

on an AWS security group. So each one is, of course, is uniquely configured based on its own

technology. But what's interesting and what we do is we normalize these policies across all these

different technologies because at the end of the, you know, when it comes to making the change,

we're trying to do the exact same thing, which is allow network security access from certain sources,

to certain destinations with certain applications and ports of protocol. So we're, we're able to

analyze all those different technologies and provide the specific recommendations for the specific

technologies. I assume there's also a compliance angle here. Yeah, it's, it's probably the biggest

business driver as to how people justify the business. So obviously we're all in a, we're all in

the security industry and we understand the problems you're trying to solve that may be security

related and then the business justifications you have to make to get the tools you need. So

compliance is one of those business justifications that is used because compliance from a network

security perspective is just hard to prove. So a few angles. First is, is every change that's

being requested, been reviewed and approved by an appropriate person in the organization? Well,

we give you that as part of our change process, right? We own an audit log of every action that was

taken and who approved it and why they approved it with all the business justifications. But then

once a policy has been in place for years, in some cases, decades, right? JJ, think about those

policies, there's firewalls you deployed 15 years ago or probably still in operation at some

organization, right? So these policies that have these firewalls that have these legacy policies,

right, that have been there forever and have hundreds or thousands of rules and an auditor comes in

and says, prove that you're not allowing access from this part of your network to this PCI

section of your network. Oh my gosh, right? Can you imagine having to do that by hand to scroll

through the policy and document that? Firemon does that automatically so that when the auditor comes in,

you click the button and said, here's my proof, here's my audit report that you asked for last year.

It's the same one that's this year and I can show you all the changes that have happened.

And of course, all the business justifications that go along with it done. So we've just taken

that that burden and oftentimes frustration off of the engineer's hands and allow them to generate

those reports without a lot of effort. So how does Firemon do this then? Are you pulling

configurations out of firewalls or looking at logs or how are you getting this information about

what my policies are doing? Where is this information going? How is Firemon delivered?

Yeah, so the inventory of policies is where it all starts. We connect to whether it's a

management session of the device specifically and pull the raw configurations from the device.

With that, we then perform what we call a normalization step, which takes all these vendor-specific

configurations. So the power author config looks wildly different from Cisco or Fortinet or

or even the zero-trust configs from an aluminum. And we take those policies and put them into a single

language that says, this is what a source object looks like and this is what a destination object

looks like. And then we build our application features on top of that. So all of the analysis,

you can write one compliance check that says, find any rule that allows external addresses to

internal addresses with clear-text protocols, create one control, and it effectively assesses all

of those different technologies without having to write a unique control for checkpoint or Cisco

any of the specific vendors. And then we also, as you alluded to, we also collect log data.

So while the policy data is incredibly powerful and really answers the risk and compliance questions,

log data gives us a different perspective, which is how is it actually being used in the real world?

So you may have a business justification to say why this rule exists, right? Allow access from

this user network to this specific server with HTTPS or whatever the application is.

But in practice, it may be that it's never used, right? It didn't actually need that application

was never used in that way. The user always went to some other server to get access to that data.

They never directly went to that particular server. And so by collecting log data, we actually get

the empirical view of access through your enterprise. And with that, we can answer some really

important questions like, is this rule needed, right? Imperically, is this rule needed?

Is it ever accessed? And if it's not, then all you have is a latent security risk, right? We're

allowing access through a firewall that is not needed. So we can help you clean up your policy based

on that log data. So that's roughly how the system works. Okay. And when you say you're collecting

the configuration and the log data, is this going to be an appliance on-prem? Do I do this in the cloud?

How is the product delivered? It is an on-prem deployed software. There can be deployed anywhere.

So many of our customers choose to deploy it in their cloud environments or on-prem in their data

centers. You know, we're supporting on-prem technology. You deploy a palo alpha firewall in

your location. Maybe it's in your physical data center or maybe it's in your virtual data center

in Azure. But that's the technology we're supporting. So we deploy our software alongside that.

It gets deployed in a distributed fashion. We are focused as the largest enterprises in the world.

So I think they're really big, complex environments. The more complex, the more painful it is

to manage your environment. If you have one firewall in a small law firm, chances are you don't

need a solution, right? It's all well contained. You've got 15 rules that say allow access out to

the web, whatever it is. And it's not a very difficult challenge. The more complex the enterprise gets,

the more important it is that you have a control plane like firewall to help you manage that. So

in these really large and complex environments, we need to scale to meet the challenges of those

large and complex environments. So the core platform itself that does all the reporting can be

distributed across multiple database servers and what we call the application server. But then we

have these things called data collectors that get deployed across the enterprise really close to

where the firewalls exist. So let's say you have 10 data centers, you probably have at least 10

data collectors, one in each data center or deployed in the cloud environment, constantly collecting

the configuration data in real time. So one point when I said that I mentioned we collect the

configuration data, we do that continuously. We detect changes in real time. And whenever we detect

a change, we go get the updated configurations. We always have a real time view of the state of

your firewall. And then the log data, as you know, when a large enterprise could be billions of

logs a second. And so distributing that log collection across those data collectors is how it's done.

So these collectors need like admin access rights to these firewalls or how do I ensure that I'm

protecting the collectors as well. Yeah. So a couple of answers. At a minimum it needs

read access and to collect the configuration data and then log data usually gets pushed to some

log collector somewhere in organization. But if you want to deploy or use firewall into to

perform automation of the change process all the way through to provisioning, then in that

in that use case, you would need the ability to provision those changes as well. And you can,

of course, control access to just like you could control access to any user, you can control access

to what policies that our system is allowed to push to. So yeah, read access to the minimum and then

in order to perform automation, you would need right access as well. And so, Jody, when you say

automation, I'm kind of that makes me think you could do this relatively hands off as in you would

do it from the console. You could push policy or update policy globally from the Firemon

console instead of just hand holding your hand through the other products that it's configuring.

It'll just magically do it for you. Yeah, magically. Yes, exactly. We like auto-magical. Sometimes

we like auto-magical. Yeah. You know, we say the word automation. It's because it's the phrase

customers embrace as well. But it's such a catch-all. When you think about our automation capabilities,

it can be automating the compliance reporting that you asked about a few minutes ago. It can be

automating the design process. It can be automating the review process. So think about that change

automation. But it can also be all the way to the end-to-end automation that we think about,

including provisioning. And that's exactly right. And most of our organizations go through some

maturation process where they start with compliance and clean up as their goals to get their hands

around what they currently have. And then grow into more and more automation all the way until

they've embraced these automation goals and are automating some portion of their overall change

requests. And so I've been a fan of the Firemon solution suite for a long time. And even a

Jody fan, very much so. I know every year at RSA, I always go find the booth, go see the update,

of course, customers back when I was doing hands-on were using the product as well. But a lot,

I think a lot, we kind of caught up a couple weeks ago in preparation for this. And I think a lot

of stuff is just obviously matured, grown, and changed. And you guys have more of a portfolio

on a suite now than just kind of like a solution. And so I think Jody, I want to kind of talk through,

you know, the different pieces and components and explain to everybody how those fit together.

And I do want to make sure we kind of talk about whatever Lumeta has come into because there was

also back in the day a really interesting solution out there that you guys acquired. And it was

funny because like not too long ago, I was talking to a Ryan's client. I'm like, there used to be this

product. And now I don't know where it is, but it's so cool. And we need to hunt it down and figure

out where it is. And here's where it is. So talk us through the portfolio.

Yeah. Well, I'll start with that. So Lumeta was a technology. If you go way back to the bell labs

days in the late 90s, there was a really cool technology that mapped the internet and these gorgeous

beautiful visualizations of the state of the internet back in the late 90s. And then they did it

in successive years. And you can see how the internet exploded through those years.

Super cool technology that Firemon acquired in 2018 that we have released as a product now that

we call asset manager. And the whole concept behind Lumeta is continuous discovery of your network.

And it seems so simple, right? You think about, of course, I know what servers are having. You may,

if you are that really small organization, when you get into a really large enterprise, this is a hard

complex problem to even understand what what servers, what what exists, right? What access points,

what what exists in your in your network. And access manager or asset manager, excuse me, does

continuous discovery using multiple different techniques, think SNMP discovery, but active discovery

across your network to discover all these different assets. And in these large enterprises,

think hundreds of thousands of nodes is quite common when we deploy asset manager that we will

discover about 30% more assets than they knew about. So if you combine all the different reporting

tools you have from your vulnerability scanners to your CMDBs and your endpoint solutions from a

from a crowd strike and you collected all those different pieces of information, we find in additional

30% you didn't know about that likely means they're not covered with the security tools that you

expected to have deployed across all your systems. And third general class of product that you

tend to discover more than others or is it a mix of a printer, a server and a desktop?

It's a pretty good mix. The ones that usually catch people's attention are things like

rogue access points that are allowing that are allowing the Wi-Fi access to your network and

you didn't expect them. Finding parts of the network that that are labs that people didn't know

about but then those those lab networks that were stood up for good reason that now all of

a sudden have internet access and are packed doors into your enterprise network. These are the kind

of things that are discovered. And yeah, the switches and in points that people put underneath

their desk, these are all the concerns that that that that security teams have that we help identify.

And just to clarify, you're doing an active discovery process as opposed to just waiting for things to

maybe pass through a firewall where you could see it from above. That's exactly right. It does

an active crawling of your network very unintrusive or it doesn't cause any network issues or it can

be controlled as to whether it does port discovery or not. In case you're worried about scanning

for open ports. But yeah, it's a very active discovery process.

One of the things I liked about it from before was like you could, there were lots of things

that a regular discovery tool would, because if they're doing like ping-sweeps and maybe a little

bit of like, you know, CDP type of looking, a lot of stuff would get missed because things would

get moves around and there would be like IP and VLAN mismatches and weird things that happen.

And so there's a lot of manual intervention we had to do as infrastructure engineers

for the discovery aspect of it that some of like the tool like you're describing with the asset

manager automated, if that's our word, a lot of the things that we had to do manually to find those

weird things that just weren't properly 100%. Exactly. Can figured, now does it, does that hook back

into the rest of the product sweet in some way? Yeah, in several ways. One, it helps complete the

map. So when we think about the capabilities of our core security manager product or policy manager

product, in order to perform analysis of what access is allowed, we do a, we call it access path

analysis, where we do a full topology view of your network to understand how traffic can traverse

from point A to point B. So it traverses, of course, the firewalls that we were just talking about,

but also the routers and switches. And how does that, how does that path work taking into account

all the routing tables across these different devices? And asset managers can help us expand that

view, particularly of layer two and layer three devices to complete that topology that makes that

access path analysis more capable, more complete. And then as we look forward, and I'll just

a tease a bit about where we're headed and how we think about the world, we believe strongly

in in zero trust concepts, those ideas that that we should start with this idea of a blank slate,

no access should be allowed unless it's explicitly allowed and it shouldn't matter whether it

is on the inside of the network and outside of the network, we should have a clear understanding

of why access is being allowed before it's granted. And the growth in that world, we see the zero

trust products like the micro segmentation products from aluminum, which we announced our

partnership with earlier this year is a big part of that evolution, moving from network segment

control with our traditional firewalls into micro segmentation with technologies like aluminum.

Well, the heart of all of that is this understanding of what assets am I trying to protect?

And so bringing asset intelligence to network security is a big part of the problem we're

trying to address as we think about our future and where we're headed as an organization.

So we see a great opportunity to bring this, like you said, this really cool technology of 20-year

history that's been doing really great stuff and how do we incorporate those

that awesome technology into how we think about solving network security challenges?

That's a huge, I mean, that's kind of a huge undertaking. I want to rewind just a tiny bit

because you made a quick, you made a, you made a reference in passing to being able to kind of

look and have some visibility into the route tables and the topology view. And I think the topology

view is another one of those, to me, it's a more recent feature that I had not had not used when

I was doing the hands-on work, which looks really cool. So what, what is, I have two questions.

The first is, what's the level of touch or visibility you have into that switch around infrastructure?

What are you doing to see that? Yeah, so same thing as we do with the firewall technology,

and with the firewalls themselves is we get down to the layer two and layer three information.

So when we collect configuration data, whether it's from a firewall or from a router or a switch,

we're pulling that interface data. The Mac tables to understand the things are connected to,

and certainly the route tables that allow us to perform that behavior analysis at a layer three

and layer four level. And then all the way up to layer seven with application awareness with

things like, like, a firewall. So a good way to think about this is, is if you were to perform

what we call access path analysis. So imagine putting in a source API, a destination API,

in an application or a port and protocol, we will walk you through step by step every,

every step that that packet would take through the network. So starting with that it entered

interface one on this device, based on the routing table, it got passed to this policy,

this security policy, it then identified that it would match rule number 787, which would allow

the traffic. It would then get sent to perhaps an address translation because the source gets hidden

behind an address. It would then get sent to perhaps a virtual route table based on however the

system was configured, match this route, which means it goes out this interface. And that was just

within one device. And then so as it exits that device, you'll see the hop that it goes based on

the routing table that got sent to this gateway address. And that gateway address was a router that

is also in our inventory. And then we perform the exact same steps. Now every device is slightly

different. So we have to model them, something we call behavior modeling, where we take these

configurations and understand the order and behavior of how these devices act on that packet.

And when I say order, when I'm talking about something like, do I do I first perform

address translation or do I first look at security table? Do I first go to the the base

routing table? Do I first look at the virtual routing table associated with a specific interface?

Right. Each of those things is is a property of the vendor's technology. How does the

vendor technology work? And we model that in the behavior. So now when you're done with this full

access path analysis, we have walked you through from that starting address to that destination

address. And it could be in a five hops or 20 hops along the way and showed you every single step

that that packet took in its in its path from that starting point to ending point answering

questions like, what's broken? Right? So why did yeah, I mean, that's that's that's huge. I didn't

even realize you guys did that because there was again, back in the day, there was a product that

did something kind of summary had that you hooked it into everything. And you could see, you know,

is it getting blocked by this route policy or this firewall rule or filter here or there?

But that's that was kind of all it did. And it was pretty expensive. It was one of those things

where I'm like, Oh God, if only every customer environment that I have to go into because the only

thing worse in managing your own firewall or your own fill in the blank is managing somebody else's

mouse because you have no clue what's go. You know, you're walking in a zero knowledge. And it's like

here, here's my however many lines of firewall config do something with this. And it was just like

there was this thing and I thought if we could put this in every environment, we could see,

you know, we could see what was going on. We could fix everything. And then then the team that's

tasked with this could just keep managing it and they would be happy. So what you just what you've

just described this kind of like, I mean, Drew and I've been like doing this now for this podcast

for a couple of years. He's been covering this segment for a long time from a editorial and

journalism perspective. And one of the things I think we both kind of agreed on is we see the

future of we have to stop separating network like land-based network stuff from everything else we

have in the security and IT ecosystem. Because the networking, whether it's, you know, on prem or

up into the cloud or some hybrid combination of those things, the packets still have to get from

point A to point B. So we have like we have to understand how that's working. And when it's not

working. But it feels like this is one of the one of the first major steps forward in bridging that

gap. And you mentioned, you know, aluminum and that micro segmentation integration. So I feel like

you guys are actually further along in this, what I'm going to call, you know, kind of bringing the

whole picture together instead of others, the data center engineers that do this type of networking

in the cloud. And then there's this and then the end-of-point team and the server team. You have a

pretty good full view already. That's exactly right. Whether it's the on-prem technology, the cloud,

the micro segmentation, being able to draw that one picture, right? The packet doesn't care whether

it was on-prem or in the cloud, right? It's got to get from point A to point B. So the management,

the operations team should have that visibility. And as far as bringing it all together, I think a good

example to show the value. Imagine you have a invested heavily in some threat prevention system,

which is awesome. And then it sends its threats off to Splunk because you've invested heavily in

these, you know, send solutions. And then you generate this alert that somebody in the organization

needs to go investigate this particular threat, right? You get an IP address. Being able to kick

off an automated process from Splunk to say, hey, go go perform a threat, a path analysis from this

potential attacker to this potential destination. Would the firewall have blocked it? Or is it open?

Which then answers a huge question in the incident response? And so we're combining all these

different security technologies to ultimately get to the answer that matters. Am I at risk?

What do I need to go do to fix this? And that's I hopefully clarifies the point of why we exist.

And but my my message about our about our mission statement, which is we're trying to help our

these these security engineers that have a really hard complex job, improve their operations

with the goal then, and ultimately improving their security.

Is this path analysis capability? Does it come within the policy manager suite? Or is it a separate

like skew or a separate feature? Yeah, native into the core base platform. If you own

any of the policy manager components, you have the the capabilities to use API.

Now, I know, you know, you're in the network security policy management space, but what you

described, it sounds a lot to me like what I'm hearing from some startups in the space, they call

a digital twin. Do you how to not to confuse the issue, but do you feel like that's a reason

about do you feel like you could also call this a digital twin or is that a separate thing? How

would you sort of parse that, you know, market categorization? No, it's the exact right categorization.

We we have not positioned it as a digital twin. I would make one caveat in that in the we solve

a security problem. We have built this to solve a security problem. So we're some of the digital

twin on the network security on the network side have they deal with the same genre of problem,

which is the configuration management is really hard and mistakes lead to, you know, configuration

mistakes lead to operational mistakes. And so identifying things like misconfigured BGP that

is causing route issues, the route propagation or the peers are misaligned and so that's not

getting the results you expect. We don't do anything related to that because we're so security

focused. So the parallel would be we're going to identify that the security rule isn't allowing

the access that you expected. And here's somewhere very deep inside of your policy. Here is the

change you need to make or even VPN awareness, right, which some of these digital twin technologies

will have blind spots. So very parallel and the right categorization. So you caught it correctly,

you understood correctly, but our our goals are slightly different. So it's interesting. You

mentioned it, you know, we've internally talked about should we position this as a digital twin,

even should we consider selling it as a is a separate product or as an independent product,

those that want to use it as a digital twin. And maybe, but at this point, we're using it to solve

these these policy problems. Okay, that's fair. And I sort of pulled you off track, but I wanted to

follow up on this path analysis capability. You met it sounds like this is a tool that can

integrate with a broader sort of either incidence analysis or sock or threat hunting package.

Well, like would you can you integrate with a sock with a set of threat hunting tools?

We do. And it's it's not native because everybody is slightly every organization is slightly

different. So the approach we've taken is that our entire platform is API accessible.

There's not a single feature or capability that we perform through our UI or reporting or

anything else that isn't also available through the API. So most of our large enterprise

organizations have gone through some API integration into their organization, whether it's simply

reporting because they've got some their own dashboards they want to pull data into or whether

it's operational such as threat response. So that's how we integrate there. And just to close

the loop on zero trust because that is definitely a topic of interest to our listeners.

It sounds like my impression is that if I am rolling out a zero trust strategy,

I can use the fireman platform to sort of check myself. Am I actually implementing zero trust?

Is it robust? Am I meeting my intended goals? Yes, and so that is probably the biggest

driver back to my comments earlier about about budget drivers. Compliance is is one of those

challenges. So that the zero trust technology, the micro segmentation technology is still pretty

nascent. I mean, it's not brand new. I folks like aluminum have been around for 10 years, but

their adoption has been a little slow. So it's still somewhat nascent technology. And with that

are some limitations, some some immaturity around compliance capabilities in these technologies.

And so we fill that gap. So if you deployed aluminum, but you also have compliance regulatory

concerns, large, you know, portion of their of their customer base is in the financial sector.

And they've got PCI requirements as an example. And we can help validate that.

I mentioned the and so and one of the big challenges with rolling out micro segmentation is that

we don't get a lot of green field opportunities. There are the occasional startups that are starting

from scratch. And they deploy 100% in AWS and probably start with a micro segmentation

in mind. And that's awesome. But for our largest enterprises in the world, they don't get to

throw away what they have in start over. Instead, they have to deploy something like aluminum in

these brown field environments where they already have how author of Fortinet or Cisco or whatever

else they have. And while it works really, really well in their in their lab setup, right,

they deploy aluminum in the lab. And it's super cool. And the policy is super cool. And the ability

to manage policy based on tags that controls these, you know, the dynamic access of the servers and

who should be able to talk to who that's super cool. And then you go into production and realize that

there are firewalls between these different parts of your network. And defining a policy in

aluminum, this is allow access from data center one server to data center two server should work

in the aluminum world breaks because the firewalls that exist between data center one and data center

are blocking that access. So how do you synchronize the policy between your your zero-trust world,

that micro segmentation policy in aluminum, and the physical world of your traditional

or, you know, traditional firewalls. Fireman's also has that problem. We identify the discrepancies

between that aluminum policy and that how out of policy, for example, this is these two are

quote out of sync. You're going to have to make a change between these in order for access to

actually work. So I would say one of the biggest challenges to vendors in the in the zero-trust

space has been the adoption challenge of getting organizations to adopt and actually deploy

the technology technology is awesome. But now how do I actually get it to fit into the legacy

enterprise environment. We're helping overcome one of those biggest challenges. All right, Jenny,

well, we've talked about, first of all, I want to say you keep talking about network policy or

network security policy management. And I think in my head for so long, I've kind of just thought

about, you know, fireman is firewall management. And so now I think that we've cracked the egg open

that there's so much more. We've talked a little bit about zero trust and micro segmentation.

I know Drew is just drooling over there because his little his little podcast bingo game is never

complete until we talk about what's happening in context of AI. I'm not going to just feel like we

have to put a quarter in the jar. We have to put a quarter in the jar if we don't do it. I'm

going to start just making you pay when we do do it. That's what I mean. Yeah, it's like a swear.

So we've kind of talked about, you know, automation and we're talking about, you know, complexity

and on-prem and cloud and then the you guys that expand into portfolio. So what what are we doing

in the world of AI and how is that impacting what fireman's doing? Yeah, I don't I get it. I don't

think you can't have these conversations without asking about AI and it's moving so fast. It's hard

to keep up. So from an AI perspective, I guess, my personal position is I believe it is a

transformation transformational technology that's going to make a huge difference to the world of

security. And from our perspective, as we think about network security operations, I think AI has

got some huge potential. Obviously, risks right. We have to start there, which is that we're

empowering these these threat actors with new tools as well. And so the speed and the capabilities

of these teams, I think you have to assume that any gap in your security is going to get exploited.

I mean, our ability to discover and then write exploits no longer requires some deep

expertise. It just requires access to a to a chatbot to go ask go build something. So you have

to come all the attackers are using LLMs that don't hallucinate and they're getting these top

not exploits when the rest of us are far set the actual output. Yeah, you wonder, right.

So if you assume that attackers are going to get better, you have to assume that the defenses

have to get better as well. So we've we've waited into the AI world about 15 months ago, I think,

at this point. We released a new product called Insights. It is a free product. You asked about

deployment earlier while our core platform is deployed on Prem Insights is a SaaS product that

that collects anonymous data from from the from these platforms across all of our customers

to provide a bunch of capabilities. Sorry, I have to interrupt. You said free.

It is free. Okay, I'll make sure I heard that right. Yes. So we we collect data and I'll

I'll get to the AI at the end, but I'll talk briefly about Insights. So we collect this anonymous

data to perform a number of a deliver a number of key capabilities. The first is we collect data

across over a hundred benchmarks. So how many unused rules, how many critical vulnerabilities

exist in your policy across a bunch of different metrics and we give you the raw data here are all

of the metrics and here's where you stand across them. Then we also trend that. Are you getting

better or worse? So you think about that that decade old policy that has a whole bunch of unused

rules or a whole bunch of high-risk rules. If you deploy fireman as an owner of the technology,

you want to make sure that you're getting a return on that investment. Am I getting better? So

am I reducing the number of high-risk vulnerabilities? Am I reducing the number of unused rules

across my organization? So we trend that data. So this means I am sending data up into this insights

tool for you to analyze. That's right. Meaning it's some firewall configuration, some logs, is that?

So we are not sending the raw configuration data or sending these metric data points. So they're

just answering the question of do I have a high-risk vulnerability? I'm not sending the high-risk

vulnerability. I've just a doubt of the high-risk vulnerabilities. And then you're able to do

benchmarking. So imagine those same data points and now you can benchmark it against your peers.

So you can say for every other customer that has hollow alto firewalls, show me what their

percentage of unused rules looks like or show me what their percentage of rules that are not

using applications, which is one of those key questions you might ask if you're interested in

application-aware firewalls. And so we can benchmark against the industry. And then the final piece

is where AI comes into it where we introduce our AI capabilities. Two big features. The first

is a chatbot. I don't think you're allowed to have a product these days without a chatbot,

so that's ours. And the chatbot, though, is not simply some textual answer around some support

question. Rather, it's a really powerful natural language search capability to answer the

common questions you have about your firewalls. So we've taken that API that allows you to do

anything like find all rules that allow SSH or find all rules from source A to destination B.

And using the LLM is the front into that. Ask questions about your firewall environment and

get back real answers. So without having to have any expertise about how fireman works, you can

just ask questions about your enterprise and JJ to your point before without having to know any

vendor specifically. You don't have to ask it in a Cisco-specific way or a hollow alto-specific

way. You just simply say what policy or what rules are allowing access from this critical server

in my organization? And we'll return back that view to you as a user by leveraging the

Core APIs system. And the final piece is an AI agent that does analysis against all those

metrics that I talked about earlier to identify where you should spend your time. So imagine

all those data points that I talked about, what do I do with the pile of metrics? It's a lot of

data. How do I as a human comprehend all of that data? Whether it's the raw data point or the

trending data or the benchmark data, how I compare to others. What we leverage is the AI agent to

analyze all that for you. And it comes back and says here are the top three or four things you should

be paying attention to right now. I saw that your high risk or let's say critical risk vulnerabilities

in your policies was fairly low. But over the last four weeks, it is trended up. You might want to

go look at what's wrong with your change operations process right now to go fix that because you're

adding risk to your to your security posture. Or unused rules is creeped up. Maybe you

deprovisioned a data center and it's time to go clean up those policies that were associated with

that data center. So that AI agent does that analysis against the against those policy metrics.

And then as we look forward, we teach tremendous opportunities to engage AI in this

agentic way to help perform those those operational responsibilities. I think at least in our space

and I'd just love to hear your thoughts on it. But in our space, I think the human and the loop

is going to is going to be important for a for a long time from security and in agentic AI

standpoint. And so we're we're definitely keeping that top of mind as we think about our future

and how we embrace AI going forward. I'm curious what you see as the role for an AI

agent in the automation space when I already have automation capabilities in policy manager.

Yeah, it's a great question. A few things. So while it's possible to automate

huge portions of your of your change requests, it's hard to automate all of them. But there's also

some I'll give you really mundane, but exciting from our customers perspective, things that we can

do with AI. When you create, when you make a change request, often it's because you have a new

application and you need new access to that new application. And so with that comes one of the most

challenging things and software development and it turns out in security as well naming things.

So what should you name the new object that you're going to create in your in your policy? What should

you how should what comment should you put on the rule? What should you name that new rule? These

are really mundane. I'm just test one test two test three or a bunch of letters shockingly.

Well, right. And so it's a really mundane thing, but it's it's cognitive overhead, right? The

the security team that has to answer these questions. And so an LLM can do that really well not

just because it's it's good at making up names, but rather because it can take in large volumes of

data. So I'll use the object as an example. A new request comes in, they give you an IP address

and you're supposed to come up with a name. Well, in most enterprises, there are 90,000 objects that

already exist across all of your policies. Using an LLM, we can say, what what's the typical

naming pattern that you've used across the rest of your organization? And we'll use that as an

input to help us guide how we should name this new object that you just requested. So there's an

example where maybe the same exact automation process is in place, but now the LLM, the agent can

help us get a little bit smarter about the little things along the way of how that gets automated.

That's interesting. Yeah, it's funny how those kind of mundane thing can I have a significant

impact? Yeah, like you laugh at this. I have because I'm a I'm a I have OCD tendencies. So anybody

that's working with me knows that drew knows that all my customers I worked with and and did

deployments. They know that I document the crap out of there, even something that's temporary,

right? Like it's documented. It's named. And I've been places working with other engineers and

it's it's you know, it's like they're troubleshooting something or testing something and they

literally will put like just letters, right? They'll just like pound on the keyboard and put a

policy. Now I can get it if you're not going to save the policy. If it's just like you brought up

the screen because you got to put in something to get to the next thing, but you're about to cancel out.

That's fine. But if you're actually putting a policy in and you name it a bunch of letters or

numbers that's random or tests or test one or test two. And then you actually put that policy in

place in it anything, right? Firewall switch, right? Any of the stuff. And then it works how you

want it to. And I remember sitting there one time and this is the conversation that went down.

I'm like, okay, now we need to rename the policy. So it's correct. And we couldn't rename the

policy in that particular product. We had to recreate the policy, but you can't create a policy with

the same policy statements as the other policy. So we literally went back and forth for several

minutes. While we were in the little troubleshooting, the thing finally worked and the in the person looked

at me. He said it's working. And I'm not I'm not undoing. I'm not breaking it to name it.

Not this is just how it's going to be. And I said, okay, fine. And it's not just, you know, it's not

just an annoyance. There's real problems with this. So if you have inconsistent named objects as

an example, these policies have tens of thousands. I mean, it's not uncommon to have over 100,000

objects. And when you have inconsistent naming, the likelihood of creating duplicates goes through

the roof, right? So if you're always named network objects net underscore, but yesterday I created

an object. I didn't use the net underscore. Well, the next time I need to use it, I searched for

net underscore. And it wasn't there. So then I created a duplicate object. And this happens all the

time. So it's, yes, Drew, as you said, it's a it's a dumb mundane problem, but it's a real problem.

It's it's one that we actually deal with and helping helping operators solve these mundane problems

makes their lives just a little bit better. So Jody, we're getting to the end of our time with you.

One thing I wanted to make sure we talked about is that that Firemon has produced a series called

cyber confessionals as a as a former Catholic that that made me perk up, but what what is this?

Yeah, yeah, that's a it's a podcast series that that we recently published just released season two of.

And it's these are the stories of real people, real operators that are dealing with the real

challenges of managing network security. They're they're not Firemon related. In fact, I don't

know if there's any Firemon stories in there other than my own, which I already shared with you.

The the origin story of Firemon was was my cyber confessional of how we how we got to this point,

but it's they're really impactful stories. I think I think most of your audience could empathize

with the pain that these people have faced, you know, oftentimes in security, security is not

the the reason for pain more often than not. Security professionals get, well, play it get fired

for things that are completely unrelated to security. They do their job really, really well

and secure something, but it causes a network outage and that network outage probably for good reason

because access should be blocked because there was a threat. But because of the outage,

then it leads to, you know, severe consequences either for the organization or for themselves.

And this these pains and challenges are real. And these are the these are the stories

from the front lines of these folks that have dealt with these problems for for many years.

Anyway, super cool. Check it out in addition to the cyber confessional which you can find from

from our homepage, but also on on the all your favorite podcasts locations that we found as well.

So yeah. And if folks want to get more information about Firemon, I assume they go to Firemon.com.

Do you have like a free trial option for the policy analyzer or anything the folks can use?

Oh, yeah, great question. So yes, if you go to our website, you'll see a demo link that that

will be a request off to our sales team to say, hey, we're interested in trying the product. But

if you want to try the product yourself without having to talk to a human, we do have a really

cool product called policy analyzer. We don't promote it a lot because it has a technical requirement

of Docker. And but if you are a technical person, you know, some in your audience is technically

capable familiar with the Docker requirements. Super easy to go register, download in a Docker

image. And then we will perform that image. We'll go collect the data. Similar to we described

earlier, collect the data from your firewall, upload the configuration data to policy analyzer.

And within seconds, you'll get back a very detailed tens of pages report, identifying all of the

risks identified in your policy. Those things we've talked about from redundant rules and

shadowed rules to high risk rules and and security concerns, those things that may be security

gaps or compliance gaps against certain compliance policies. So really simple and free way

to try out a product from fireman to understand the importance of policy management.

Okay, so that's called policy analyzer. I will have a link to it in the show notes along with

links to cyber confessional and of course to to fireman.com in general. Jody, thanks for being here.

This was a really interesting conversation. And thanks to your listeners for coming to another

episode of Packet Protector. If you have a topic you want us to cover or a comment or a correction

or a question you can reach out at packapotures.net slash FU. The FUs for follow up and we love

when listeners reach out and we will respond. And just to let you know, Packet Protector is part of

the larger packet pushers podcast network. We've got more than a dozen technical podcasts for your

professional development on networking security IPv6 DevOps leadership and more. We have an industry

blog two weekly newsletters including human infrastructure work, which comes out every Thursday.

We've got a community Slack group, a YouTube channel, even an IRC group. You can find it all

at packapotures.net. Always free. No login required. Thanks for listening.