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

0:00Hi 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.

1:02Yeah, 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

2:03firewalls 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

3:08there, 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

4:10suckiness. 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

5:11complex 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

6:14where? 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

7:14of 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

8:17question. 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

9:20it. 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,

10:22and 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,

11:25we'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

12:29policies, 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

13:34what 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

14:39any 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

15:43allowing 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

16:46to 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

17:48a 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

18:52in 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

19:54maturation 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,

20:55you 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

21:57we 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

22:58from 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

24:02maybe 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

25:08into 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

26:09in 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

27:11history 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,

28:16and 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

29:20within 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

30:20address. 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,

31:22you 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

32:27you 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

33:29off 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.

34:33Now, 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

35:37is 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

36:41follow 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.

37:43It 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.

38:44I 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

39:48in 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

40:50network 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

41:54transformation 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,

43:01at 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

44:04rules 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

45:06application-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

46:09vendor 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

47:12go 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.

48:17Yeah, 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

49:22just 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

50:23deployments. 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

51:23the 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.

52:25It'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

53:27with 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.

54:31So 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

55:39risks 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.

56:41We'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.