Loading...
Loading...

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.
