How to Prove Your Firewalls Actually Do What You Intend

On-Demand

Video Transcription

Randy Franklin Smith:
Good day everybody, Randy Franklin Smith here. And today, we’ve got a great Real Training for Free session planned for you. We’re going to talk about how to test firewalls and, just, why it’s so important to test firewalls, and why it’s so difficult to test firewalls. But we’re going to show you the best that technology can provide. And speaking of that, I want to thank FireMon for making today’s Real Training for Free possible. Tim, I got Tim Woods with me here from FireMon. Tim, it’s good to have you back and thanks for sponsoring today’s session.

Tim Woods:
Yeah. It’s our pleasure. Always, great being with you here, Randy.

Randy Franklin Smith:
All right. Well, we look forward to seeing the really awesome technology that you’ve got. I love it because, at the end of the day, folks, what we’re doing really, is just a math problem. Tim’s the one that pointed that out. You know what I’m saying, Tim, at the end of the day, it’s just a math problem.

Tim Woods:
It really is. I mean, when we’re looking at access rules and who can go where, and logical values against those rules, and logical paths against those rules, much of it is a math equation. We can figure that out. There is some value to gaining some statistical knowledge to assist statistical analysis behind the behavior of the rules. And, I’ll demonstrate some of that at the end of the webinar as well.

Randy Franklin Smith:
Okay. So here’s the thing. Everybody’s got firewalls. A lot of organizations have got gobs of firewalls. And we’ve spent a lot of money on them. And we’ve spent a lot of time configuring them. But in a lot of conversations, I have come to the belated realization that most of us out there know that our firewall is allowing the traffic we want it to allow, but very few of us know if it’s really blocking the traffic that we don’t want to allow. And that’s pretty darn scary.

Randy Franklin Smith:
I’ve talked to firewall admins of really big companies, and they admitted it. I said, “Well, how do you test it?” And they’re like, “There’s no way.” And they just give me a list of excuses. We’re going to drill down into all that, but let’s just take a step back and say that, isn’t it reasonable, don’t we all agree that in IT, in anything technology related, until it’s proven, until it’s tested and passes a test, we should conclude it’s not working the way we expect. How many of us, Tim, I don’t know, were you ever an admin? How many times have you, a customer said, “I need this.” You configure it. You walk away. They call you five minutes later, or the next day, it’s still not working. Why? Some typo or something overlooked. You know what I’m saying, Tim?

Tim Woods:
Yeah. Sometimes you assume. I’ve been caught in that position, where I assumed it was working one way, only to find out that it was working another. Thinking you’d done something, but then going back to test the behavior, or the policy, to verify that it’s doing what you think it is doing, sometimes that can be an extended manual process, we’ll call it. And so it really gets back to time in the day. One of the luxuries of my position here at FireMon, I’ve been with FireMon for quite a while, going on 11 years. We get to talk to customers across almost every single market vertical, very large enterprise, just every type of imaginable type of security infrastructure. But, at the end of the day, some really incredibly smart people as well, but it gets back to just having the time to do what it is that needs to get done, and just prioritizing that. Unfortunately, sometimes firewall maintenance gets put at the back burner. It’s just a reality.

Randy Franklin Smith:
Right. Well, my point is really, just in general, that you’ve got to figure something’s not working until it’s proven that it is. Like James, thank you, James. Unexpected loss of blood is assumed to be cancer until it’s proven that it’s not. So there you go. A lot of times when people say, “Oh, we tested the firewall.” What they’re doing is they’re testing that it’s not blocking wanted traffic. They haven’t tested and proven that it’s blocking unwanted traffic. And a lot of folks will say, we just have to assess it by reviewing the rules. And so we have a review team. Someone else up here has to review any rule changes made. But come on. You can’t review rules and be sure that they’re working the way you think. Rules in a firewall are fundamentally no different than source code in a program. Maybe they’re just a bit more homogenous and structured. But coming from a software development background, yes, we had a peer review our code, but we also had to test it. And the review was more for style, and were certain standards being followed? Not to find bugs.

Randy Franklin Smith:
James says in the old days we used to have a test deck of input check. Yeah, absolutely. All right. So, hopefully, I’m preaching to the converted on all of this. But the other thing here is, firewall policies today are just huge. I mean, it is by no means unusual. In fact, it’s routine to find a firewall with hundreds and thousands of rules. And you can get into hundreds of thousands of rules if you look at all your firewalls for a global organization. So look, if you don’t test your firewalls, you do not know if they’re protecting you. And you should not conclude that they are protecting you. Furthermore, testing of firewalls really requires multiple vantage points. Let’s talk about that here in just a second. Really, it’s not just testing a firewall. Really, ideally, we would want to test each zone against every other zone.

Randy Franklin Smith:
So let me just give you a couple examples of what I mean. Maybe you have a retail PCI network where all of your retail point of sale devices are. And you’ve also got a data center. You probably have virtualization. And you probably have a virtualization management network, among other things. Maybe you have a call center of very limited users. Hopefully, these are all divided into different zones or segments. I shy away from using the word segment because that can mean something specific in networking, so I’m going with the term zones. But hopefully you’ve got multiple zones of routing and traffic restriction on your network segmentation. And hopefully not everybody can talk to everybody else on the network. Now I’m saying hopefully, because over and over and over again, we run into reports of intrusions where we get enough details to be sure that we can state that they did not have sufficient internal segmentation in their network. But still, most of us do have some zones of control.

Randy Franklin Smith:
My point is, let’s take our management network of our virtualization infrastructure. So that’s the network that all of our ESXi boxes or hypervisors communicate with each other, along with the management console of those, like vCenter, if you’ve got that, or system center virtualization manager, if you’re on Hyper-V. So, is it sufficient to test the firewall guarding your management network from just one location, like your call center network? No. Because, I mean, come on, we all know how firewall rules work. It’s not just the destination, but it’s also the source address.

Randy Franklin Smith:
So, here’s the other interesting thing. And this is the thing that is the stickiest wicked out of the whole game to me. And that is, what if the target behind the firewall doesn’t answer? Can you conclude that it’s the firewall blocking that access? That is the other really scary thing. Is it a fact that the firewall is doing its job? Or is the firewall passing the traffic, but the destination port and destination source address you’re hitting just isn’t answering back, for a variety of reasons? Maybe there’s actually nothing there, at that IP address. Maybe there is a system at that IP address, but that port is not open, it’s just not part of its attack surface. Or maybe, there are some host firewall rules there that’s blocking it. You don’t know. So this is why we’re doing this webinar.

Randy Franklin Smith:
So how do we handle the multiple vantage point thing? Well, the ultimate is if you’ve got VLANs. But let’s go ahead and talk about that really quick. If you have your network all on, basically, one set of commonly configured switches, they all have trunks connecting each other, and your whole network is flattened out into a bunch of VLANs. And so what we’re saying is each zone of traffic restriction corresponds to a VLAN. Now, it’s really awesome for being able to get multiple vantage points. So here is the system that you’re using. Let’s get my pointer out. So here’s the system that you are running your scan from. And here’s the firewall that you’re testing. And let’s just imagine behind it is the target zone that you’re trying to see, can you get into this target zone from here?

Randy Franklin Smith:
Well, of course from here needs to be, ideally, tested from each one of your other zones. Because that way, we’re testing not just our source elements of the rule, sorry, our destination elements of the rule, but also the source elements. So, if everything is available as a VLAN, then it’s really nice. All we have to do is say, okay, this PC is now on our purple VLAN. And so we test that firewall and we scan the addresses and ports behind that firewall, and we prove yay or nay with regard to that VLAN as our source, as our vantage point. Then same PC, we don’t move anything. We just connect it to a different VLAN. And here I’ve got a screenshot of my Ubiquiti switch here. If my PC is plugged into port three, all I’ve got to do is change the switch profile. And all of a sudden, I’m on this VLAN. And I can run the same test, and so on.

Randy Franklin Smith:
So that’s beautiful if your entire network is organized into VLANs, and they’re all reachable from your physical vantage point. For a lot of us though, that isn’t quite the situation. So we’ve got other possibilities. At the opposite end of the spectrum, is just sneakernet. We take our laptop within map, or whatever our scanner is, and we travel physically to that floor, that building, or that data center, or other location, and run the test that way. So that’s the opposite end of the spectrum, as close to the stone age as you can get.

Randy Franklin Smith:
What are some things in between? Well, if this is a vantage point that you want to frequently do tests from, and your vulnerability scanner supports it, there are vulnerability scanners that support remote scanning agents. So you can deploy VMs around the world that are connected to the necessary vantage points, and you can run your scans that way. But some other things that I’ve seen is actually VPNing across your network into some other zone, and then using that as your vantage point. Or, and this will probably make people the most, of course, that’s only going to work, the latter, that is, VPNs, if you can get a VPN set up and if you can get it routed all the way across your network. But you’re probably going to be beating your head against the wall, against other intervening firewalls.

Randy Franklin Smith:
So here is something else that I’ve actually seen. Don’t know if you’ll like it, or if it’ll make you nervous or not. But I’ve seen laptops with, and I can’t wait to hear what you think of this, Tim, but laptops with an LTE card plugged into it. You ship it to wherever, and you tell whoever’s there co-located that side, “Okay, plug this thing into your network.” And you go to my PC into this drop and go device, via LTE, and then you run your scan physically from that vantage point. How do you like that one, Tim?

Tim Woods:
I like it. And I’ve done it. I’ve used it. Whatever it takes to get the job done sometimes.

Randy Franklin Smith:
Yeah. So there are ways to do this. There are ways to get to the different vantage points that you need. But certainly, VLAN is the nicest. But here, I just want to make sure we’re on the same page when I say that vantage points really matter. So you may run a test. So we’re trying to determine, is this network down here protected by the firewall the way we think it is? Is it really blocking the traffic that when we read the policy on that firewall, we conclude? So, is the actual configuration matching our intent? So we run the scan from up here, from the 10.42.0, and we are, let’s see, we’re allowed through. Did I draw this wrong. I kind of went backwards. So here’s the thing. When we run the scan from 10.42.1, we’re blocked. And that’s what we want. But what we don’t realize is if we go and run the very same scan, but originating from here, we’re allowed through because of this additional rule. So my animations came up in the opposite order that I really wanted. But, hopefully, you guys get the point. Vantage point matters.

Randy Franklin Smith:
When you test something from 10.42.1 sub-net against the 10.42.3 sub-net, what have you proven? You’ve proven that your firewall blocks that unwanted traffic, with that source against that destination. But that’s all you’ve proven. You haven’t proven that it’s also going to block it from the 10.42.0 segment, or any others for that matter. Now, Tim, I guess some people would argue, “Well, come on, I can look at the policy. And the policy says for source = any. So if I test it from one place, then I’m good. You know what I’m saying? And I guess that’s fair enough, if the rule says, source = any, then great. If you’re sure there’s nothing else intervening. But that’s a very possible thing too, Tim, is you think you’re testing that rule, but wait, 20 pages up, scrolling wise, there’s a policy that allows that very traffic. That’s totally an issue you guys run into. I know we were talking about this in the preparation.

Tim Woods:
Yeah. And again, doing this for a very long time. It used to be that a large firewall policy was 300, 400 rules. And that was pretty significant. And then they got up working on some of the early CheckPoint 1, firewall 1 firewalls. They got up to over a thousand. When I saw my first Check Point that had over 1200 rules in it. I’m like, “Wow, how do you manage something with this many rules?” And now it’s routine that we see firewalls with 4000, 5000, 8000 rules. I’ve seen Ciscos with 40,000 rules and more. So it’s just crazy. It’s just something that’s not humanly possible to put your eyes on and try to actually determine what the policy behavior is. And I’ll talk about this a little bit too, about shadowed rules and redundant rules. And if you miss a rule that is a duplicate of some other rule, but yet has the opposite action, what we call a shadowed rule, that’s very easy to miss as well.

Tim Woods:
But these rule bases have just grown astronomically. And just the sheer volume of rules in the environments that our customers are faced with has almost, it’s 8X, 9X what it was four years ago. And it’s driven by a lot of different factors. But it’s really hard. I get it. I absolutely appreciate the challenge that the security IT professionals are faced with today in managing their firewall infrastructure.

Randy Franklin Smith:
So the bottom line is, and all I’m really trying to make here is that as soon as you say, “Well, I can read the rule on the firewall and conclude from that, X. You’re on thin ice, at that point. We talked about VLANs. Now here’s the next thing. Same situation as before. What’s the difference? In both cases, that computer on 10.42.1 does not successfully communicate with 10.42.3 on port 81. See, the line is red in both cases. But the difference is it’s being blocked at the firewall, which is what we want here on this slide. But down here, it’s actually being blocked because of a host level firewall, like Windows firewall rule, down there on the actual host. Or, like I said, maybe there’s no device there at all, at 3.2. Or maybe there is, but it’s a Linux box. And so it doesn’t have port 3389 open. Any of those things could be true.

Randy Franklin Smith:
So, this is a difficult thing. When you are scanning on one side of a firewall against retral targets behind that firewall, then when you’re not able to connect on a given port, it could mean that the firewall is doing its job, or it could mean any one of those other issues. So how do we know? Again, unfortunately, we haven’t proven anything. All we’ve proven is we’re not able to communicate with that particular IP address, on that particular port, from our current vantage point.

Randy Franklin Smith:
… and that is another sticky wicket here. Let me just check a couple of my questions here. James says, “What about virtual environments? Nonresponsive devices may be shut off.” Great point James. CJ says Randy, “That’s what I’ve seen a lot, rules referring to non-existent devices.” Oh, well there’s another issue, right? Tim. I don’t want you to go into detail on it right now, but that is another big thing, is just outdated rules that don’t mean anything anymore, but how do you know which ones are of that criteria? How do you know you can get rid of them? They also are actually a big risk because CJ, what if we redeploy something on that IP address, and suddenly that rule is now opening up some light to get in?

Randy Franklin Smith:
I guess what I’m trying to say is outdated rules that refer to non-existent devices are more than just bloat. They are a hole in the firewall that is going to expose you to risk, as soon as you do play something within that address space. Yeah. CJ gets, he says, “Exactly.” How do we deal with this? How do we deal with either nonexistent, retral targets, or a retral target that’s been hardened? Well, there’s an interesting technique called Firewalking. It was developed by some cool guys, and it’s intent is to figure out if a firewall is passing traffic without actually reaching the specified host, how in the world would that be possible? So the cool thing is when Firewalking works, you don’t even need to have any device on the target IP address that you’re testing.

Randy Franklin Smith:
You’re truly, with Firewalking testing the actual firewalls policy, with zero dependencies on there being an actual device there. How does it work? It uses time to live, or TTL. So every packet has a TTL. It’s not really time. It’s really hops. How many hops is this packet allowed to go, every single time a router forwards a packet, it detriments that TTL. When a router gets it, and as it’s about to detriment it hits zero, it drops that packet, and if it’s compliant, it sends back a message saying, “Time exceeded.” That’s what we’re relying on here with Firewalking. So what we do is, we figure out, how many hops away the firewall is. Then we add one to that number. Then we send a connection request to our retral target IP address, and port number, and if we get back a time exceeded message. Then what does that tell us?

Randy Franklin Smith:
Well, the number of hops mean that it made it through that firewall, yet we got a time exceeded message back. So that means an intervening router that has retral to the firewall, but upstream from the actual target, caught that packet, and answered us back saying time exceeded. That proves to us that the firewall passed the traffic without us ever even talking to whatever that destination system is. Would you like to see this? Well, I’ll show it to you in two different ways. There’s actually utility, and it’s in Kali called Firewalk, and it’s really simple. All you do is after you… on the Kali box, just run apt-get, and install firewalk. Once you’ve got it, just make sure you’re running it with route authority.

Randy Franklin Smith:
So here, if you look right here on this line, I’ll show you the command that I’m running. We’re saying firewalk, I want you to connect on TCP or, or try to, and the destination port I want you to use is 3389. Use my Ethernet 0 Nick, and don’t try to resolve host names, that’s what the n is, and my firewall that I’m testing is 10 42.10.1, and I want you to test to see if firewall 10 42.10.1, allows traffic on 3389 from my IP address to that target there, 10 42.3.2. So let’s see. What did it say? It says, we’re running a TCP based command. We’re in our ramping phase, we are hitting just a random destination port, and counting up how long it takes to get there. Basically it’s like a trace route, and we see, Oh, wow, 10 42.10.1, that firewall is only one hop away. Okay.

Randy Franklin Smith:
So that means we bind the scan at two hops, meaning all of our connection requests to that port, or if we were doing a range of ports, we put an artificial TTL on it of two. Normally it’s more like 128. So now we try to access port 3389, and our conclusion is that it’s open. Why? Because we got an expired message back. The fact that we got an expired message saying, “Hey, you exceeded your TTL on that packet,” means that the firewall past the traffic, and it doesn’t matter if there’s actually a device here, or an end point at 10 42.3.2. It doesn’t matter if that port is truly open on it, or not. Even if the port is closed, or if it has a host firewall there that’s silently dropping the packet.

Randy Franklin Smith:
It doesn’t matter, because the packet never makes it there. It just gets past the firewall that we’re testing, or doesn’t. How would the same thing look, if we tested it against the same destination IP address, but against a port that is being blocked by that firewall? Let me see if I can bring that up for you real quick here. Let’s see here. We want our Kali box. Now we are going to run this, instead of port 3389, we’re going to run it with port 81, and that’s the only difference. Security maturity. It reached the same conclusion, as far as the TTL. It bound the scan at two hops, again. It sent out a connection request to port 81, and if you notice there’s a little bit of lag, because it was waiting, and it got no response. So the conclusion is that that port is not open.

Randy Franklin Smith:
In both cases, I did not communicate at all with 10 42.3.2. We’re just testing the firewall policy itself. So to see this visually, then architecturally. Here’s our testing system, our scanner, maybe Kali Linux. Here is the firewall that we’re testing. Here is a downstream router. The first thing we do is we send out a connection request on port 81, and that’s stopped there at the router. How do we know? Because we get no time exceeded reply back. Whereas we send a connection request. Sorry, sorry, sorry, because we get no time exceeded back. So then we send a connection request on port 3389. It gets through the firewall that were being tested. It hits that downstream router, 10 42.1.1. At that point, TTL reaches zero, and so that router does not forward the packet on to the actual device, even if it’s there, and instead sends back a time exceeded message.

Randy Franklin Smith:
We get that back, and we conclude that the firewall we’re testing allows 3389 through. Pretty neat stuff. There’s just one big caveat. Going back here. Let me circle this. This is the big letdown for me, Tim. Firewalking is unreliable, if the retral target is only one hop from the firewall. That may be what you’re seeing, Tom. Tom says, “I’m trying the same thing on my lab network, but seeing no response on a reachable host.” Where’s our slide, there we go. Firewalking depends on this being between here, and here. So here’s the firewall we’re testing. Here’s the retral target IP address, and this was in logical address space, not necessarily… there’s again, no dependence on an actual physical device being there, but there needs to be a router in between it, because otherwise, if there’s just one hop from here to here, then the TTL is going to be encountered here on the firewall, and you’re not going to get that reply back.

Randy Franklin Smith:
So I found this out, Tim, by the way in my testing, because I was like, “Hey, this isn’t working. Is my firewall just so brilliant, or something?” No, it was the hop count. At first, I thought the hop count applied to between the tester, and the firewall. But no, it’s how many hops is the destination address beyond the firewall that you’re testing. So firewalking may work in some cases for you folks, but definitely not in all cases. Tom says, “That’s the exact setup. The two appliances are connected via VPN.” Okay. So here’s my thing then, firewall rules have got to be tested if we’re going to rely on them, but testing firewalls is complex, it’s laborious, it’s time-consuming, it’s impractical for a lot of you, not for all of us. So what should you do? Well, you might not be able to do the ideal, right? The ideal is to test every zone that is protected from every other zone on your network.

Randy Franklin Smith:
Given all the complexities that we’ve talked about, and just given the amount of time in the day, and all your other responsibilities, you may not be able to do that much. What I would at least recommend is that you think of every few months as you do the firewall testing, then you should really go out there, and think of, what are some things we definitely would want to prevent? What are some important types of traffic from this destination to that, that if a bad guy… and think of it in terms of a bad guy, if they broke into one of the PCs on our call center fleet, and through a phishing email, then what lateral movement do we want to prevent?

Randy Franklin Smith:
Then at least try things like that. That is definitely not quantitative, but it’s certainly qualitative. Qualitative is better than zero, but I have something better to offer you than that. At the end of the day, everything we’re talking about, it really does not require you to physically, or otherwise be at that vantage point, and send packets out. In fact, that’s really my point, to do what we’re trying to do to test a firewall, it’s really a math problem. You don’t really need to send any packets, if you could just reliably, and automatically evaluate your firewall rules, and run different simulations. That’s exactly what you can do, Tim with FireMon.

Tim Woods:
It is Randy, we try to take a little bit of the complexity out, and make some of the hard stuff easy here. I’m going to… Here we go. All right. So I’m going to walk everybody through just a couple of slides here. We’re not going to get too detailed, but introduce you to FireMon, but more importantly, I’m going to jump into the actual platform, and give you some real-world examples of what Randy was talking about within our test environment, and show you some things that I think you’ll find pretty interesting. I loved the question. Let me go back up here, and look at again. I think so James, go to meeting is blocking my firewall, but the question, in fact, I think it was you that asked, it’s like, who owns the firewall rules?

Tim Woods:
That’s probably one of the best questions I’ve seen come across on the webinars lately, because it’s such a loaded question, and it gets into, who’s the business owner for the rule. Who’s the IT firewall person responsible for that rule, and as we start looking at the cloud, and getting to the cloud, we’re finding that rule ownership, or we’ll call security control ownership, is all over the map. I’m seeing DevOps take responsibility. I’m seeing the application owners take responsibility for creating their data controls, our security controls. In some point I am seeing the IT security teams, but then I’m also seeing some new cloud security teams developing as well. So what a loaded question. It’s definitely all over the map, and we’re getting away from what I will call a central security policy as well, that dictates how we create those rules, and manage those rules.

Tim Woods:
The other thing, Randy, about testing your rules, a lot of the compliance initiatives out there require you to at least review your rules on some frequency, or some level, and then you have to provide documentary proof that you’ve done that review, and what the outcome of that review was. So that can be a challenge too, because again, it gets back to the amount of hours in the day, and all the priorities that we have on our plate, and how many of those things we can get to. It’s not that we don’t know what to do, and we’re very smart people out there. I get the luxury of talking to some of the brightest minds on the planet, I feel like. At the end of the day, it’s just having the time to do the things that I need to do.

Tim Woods:
Anyway, very quickly. So I’m going to show you this first slide. This is just an introduction to FireMon. It’s a full platform. It’s a full suite. Today we’re just going to talk about Security Manager, which is at the core of FireMon, and I’m going to show you a few things there, but I first want to show you how we develop some of the material, or some of the content that you’ll see on FireMon across our solution platform. So this center part here is what we’re going to spend some time just walking through, and letting you see what some of the data looks like within the actual solution. So rather than showing you a drawn out PowerPoint, I’m going to show you a demonstration of the actual product here, and just back up some of the things that Randy was showing.

Tim Woods:
I mean, for me, and I’ll date myself here just a second, but I remember, Oh my goodness, going back to the day, whenever my first introduction to the firewall was on a Gauntlet Firewall by a company called Trusted Information Systems. It was a proxy firewall, and then I got my fingers into Raptor, which was owned by Symantec at the time, and then we delve off into Firewall-1, into Check Point, and Stonebeat, and later Stonebeat came out, or Stonesoft came out with their own firewall, and so on, and so forth. Today FireMon supports roughly 50 different firewall permutations. Although back in the day, we started by just managing one, and trying to extract a behavioral analysis out of the firewall policies there, which was very beneficial, but we’ve come a long way since then.

Tim Woods:
We now have a very highly scalable environment, very distributed architectures, restful APIs, and very high performance with integrated Elasticsearch, and an integrated security query language that I’m going to show you. Again, today, we’re just going to talk about the center part here, but I’m going to touch on these just on this slide only. So policy optimizer, this is a rule recertification piece to automate that process, and then you have the workflow automation piece, risk analysis, I am going to give you just a glimpse of this, because I think it’s just really cool technology. Number one, this is where we can actually import vulnerability scan data, and correlate that, or relationally link that to the policies in force on our enforcement points as well.

Tim Woods:
Global policy controller. This is where we shift our focus to the application, and the resources, and we build a policy around it from a security intent, collaborative perspective. Then Lumeta, that you see over here is a recent acquisition we made, and it’s become an integrated component of our solution, but Lumeta is all about validating your address space, validating your edge, conducting a census, and IDing all the devices that are out there. You can’t secure what you can’t see, you can’t protect what you don’t know about. So you need this continual awareness, this continual situational awareness of what’s going on in your network.

Tim Woods:
Today more than ever as we get into these hybrid environments, the world is changing very quickly, businesses accelerating, and sometimes our ability to put the security controls in, is not as consistent as we’d like it to be, but understanding what your environment looks like at any given point in time is so critically important today. So first I just want to show you a simple FireMon deployment. I feel like if I show you how the wheels work, how some of the gears, and the process work, then when I start showing you the data in the platform itself, then it’ll make a little bit more sense, but essentially there’s three components here that we’re going to talk about. There’s an application server. This is really where we interface. This is where you would come in to get the information that you want to look at.

Tim Woods:
The database is where we store the information. I’m going to talk about that a little bit more of what we actually put in there. The data collector, very interesting component. The data collector. It does a lot more, but I call it my glorified parsing engine. So it actually looks at log information coming from the things that we’re monitoring real time. We parse that data real time, and then we extract intelligence out of that, and we look for some other things, and I’m going to talk about that, but for a small environment, I can put…

Tim Woods:
I want to talk about that. But for a small environment, I can put all this on a single appliance. This can all be virtualized as well, but we provide purpose-built appliances that you can put all these components fit on here. But you can also break this out for larger environments If we need to scale, I can distribute the data collectors and again, they can be a physical compute platform, or it can actually be a virtual compute platform just really depends upon your environment. But you can have as many data collectors as you need to fit the size of the environment. A single data collector can support close to 300, 400 firewalls just to put it into perspective. So we have customers that have 10 firewalls, and we have customers that have 10,000 firewalls.

Tim Woods:
So very… we have some incredibly large environments and of course, to support some of those incredibly large environments. Then you have to start looking at how you cluster your application servers, how you distribute your data collectors in a horizontally distributed scaled environment. We cluster everything. We make everything redundant. And so it builds out. And we size everything to the size of the environment. Because at the end of the day, it has to be responsive. We still want to hold ourselves to very quick responses for the information that we’re trying to derive. Especially whenever we’re looking at things. Everything that we do is real time. So, what brands of firewall? Daniel asked here, so Daniel I’d have to go down the list, but you name it. I mean, it’s Palo, it’s Checkpoint, it’s Fortinet, it’s Cisco, Cisco ASA, it’s Firepower, it’s SonicWall, Huawei, SECUI, On Labs, Hillstone, probably some that you haven’t heard of.

Tim Woods:
And it just goes Forcepoint previously Stonesoft, previously McAfee, Sidewinder, NSX, Juniper, SRX, NetScreen. I mean, you name it. It’s all under the platform. Lumeta is great, awesome. Awesome that’s now part of FireMon. Thank you for that. I think it’s awesome technology too. I was very excited, whenever we announced that acquisition. It really going to extend our vision of what we’re doing as well. So very excited about the Lumeta acquisition and what that means to our platform. So let’s talk about what we’re looking at here. How do we get the data? As I’m showing you this, you’d be surprised the intelligence that you can extract out of log data. So what you’re seeing over here to the right, this is just the… these are the sources of logs generation.

Tim Woods:
Typically, you go to… I can get the log data directly from the enforcement point. If it’s putting it out, most often we’re getting it from the management station or the dedicated log station. I can get it directly if I’m talking about AWS or Azure or Google Cloud Platform, they have logged data stream to there. I can get it from the SIM or the log server as a redirection or a reflection or a forward as well. Even if they munch the header, I can go down into it, because I need to understand where that source packet is coming from. But that’s where the log data comes from, that we’re looking at. Again, most often, most of these have a common management platform. So most of the information that I need is on the common management platform.

Tim Woods:
So I can get all the information I need about the enforcement technologies or the enforcement points themselves from the center platform. But if I need to talk directly to the enforcement point itself or the firewall itself, and I say firewall, because it’s not just firewalls. We support firewalls and routers and switches and load balancers and things like that. Basically anything that has an ACL that you’re looking at or some type of a rule, right? I can get information about that. So, what’s some of the information that we extract from this log data is we’ll bring it in. Very quickly I’ll show you here.

Tim Woods:
We look at hit counts against the rules. We look at object hits, which is equally important sometimes. Yes, we support RAD, we sure do. Yes, we support AWS security groups as well. So I’m trying to keep an eye on my questions here. I love the questions guys. So keep them coming. But we look at rule hit counts, we look at object hit counts, we look at session information, who’s talking to who. And probably most important in addition to the analytics that I’m developing, but I’m also looking at change detection. So anything in that log stream that gives me an indication that there has been a change to that policy, right? Again, and we’re talking about real time, real time detection here of change. And so when I detect a change, when I detect a change, that’s happened on a policy, the data collector holds the credentials to the devices that you’re allowing me to monitor it, that we’re monitoring for you and the data collector will actually log in to that management platform or directly to the enforcement point of necessary.

Tim Woods:
And we will conduct a retrieval of that freshly modified configuration. Now, up until this point, I don’t necessarily know what’s changed. All’s I know is something has changed. I don’t know what’s changed, but I’m going to log in, I’m going to initiate a retrieval of that freshly modified configuration. And by the way, when I initiate that retrieval, I’m also getting not only the policy, but I’m trying to extract as much route intelligence as I can from the route tables on that enforcement point or on that router or switch as I can as well. Because, you’ll see how I use that to build out a depiction of your network topology, as well, as far as who’s talking to who and things like that. So, and I’ll give you an example of that. You’ll get to see that here in just a second.

Tim Woods:
But anyway, we log in, we get the configuration and we… The first thing we do with that new config is we normalize it. And what do I mean by normalization? Well, we’re applying a schema to that, and I told you I would go back and talk about what we put in the database here as we go back. And so I normalize that at the application server, and then I store that on the database. So when I’m inside a FireMon, when I’m inside a security manager, I don’t care what my policy is. I don’t care if it’s Fortinet or Palo or Checkpoint or AWS or Azure or NSX or whatever it happens to be. All of my policies are going to look the same. So we give you a common plane of glass, a central view where we normalize everything and everything looks the same in this center pane of glass. So that’s one of the value propositions. How do you treat rules with zero hit counts? We’ll talk about that. Do you support Sophos, unfortunately, no, I do not support Sophos today.

Tim Woods:
Yes, we will. When we look at the vulnerability stuff, so that’s what the vulnerability scan. So the question was in your interaction with the vulnerability scanner, will you report on vulnerabilities on the end points that could cause a bypass of the firewall entirely? What we’re really looking at there is we’re trying to look at… we’re correlating the vulnerabilities as it relates to what your compensating controls allow. So, are those vulnerabilities accessible? So if a bad actor came in a well-known threat entry point, how far could they get, and what known vulnerabilities that you have on your network, could they potentially exploit? I’ll give you… In fact I’ll do it better, I will actually show you a demonstration. I’ll show you a demonstration of that as well. But anyway, we normalize those policies and then we store those in the database.

Tim Woods:
The first thing that I do is once I put that policy in the database, or once I’ve normalized it and stored in the database, I already have a picture of the previous policy. And so I’ll do a differential comparison and I will extract the delta, the difference. So I’ll give you a really nice change report. The who, the what, the when, the where all the details of that change. But now that I have this stored in the database, I can, this gets us into compliance now, I can run a compliance check against it. I can look at… I can run an assessment that has controls to say, “Hey, not only am I going to show you that a change happened when it happened, who made the change, what was the details of the change, What device was it changed on?”

Tim Woods:
But I’m also going to run… I’m going to give you the ability to run an assessment to say, “Hey,” And it could be a best practice assessment, it could be PCI, it could be FISMA, it could be whatever, NIS. We have so many, I’ll give you a glimpse of some of those as well, but very quickly I could see if somebody changed something that had a negative impact on my compliance posture, right? Or something that I need to take more of an immediate action on. And that gets into our zones of control. Randy, very well highlighted. Typically, you try to group things from a control perspective into zones, and we definitely support that as well. We call them zones of control. And whether it’s my PCI zone or my DMZ zone, or whether it’s my HR compute zone, my DevOps or whatever it happens to be, we try to put those things into zones of control so we can break them down. Especially in very large networks, it’s important to break things down into more usable bite sized chunks, we’ll call it.

Tim Woods:
All right. Lets… do you support Cisco Meraki? What a great question? It just so happens in our very last release, we’re proud to introduce Meraki support. So that is a big yes, to that question. Very soon hopefully we’ll be on the Meraki marketplace as well. So you’ll see us showing up there. I’m in talks with those guys. Can your solution work without getting logged and only work on the configuration it extracted from the device? It absolutely can. Now I lose a little bit of my dynamics. There’s some importance to looking at that log data and correlating that log data, and this is the hard part here guys.

Tim Woods:
Correlating real time log data to a policy that’s enforced, is really important because that’s where the context, the policy is my context, the log data gives me behavioral analysis and allows me to… So when I’m correlating that log data to the policy it’s enforced, there’s some real good information that comes out of that. I’m going to show you some of that. But I can also import a configuration and take action on it without having the log data. I can actually do a scheduled poll where I say, “Hey, I don’t get the log data, so I can’t detect change.” But I can periodically go and look at a device and just say, on whatever period you want me to go look at that, every two hours, once a day, every two days, once a week, whatever I can go look at it and say, “Hey, here’s my old config. I want to compare it to the kit config. that’s on this device now.”

Tim Woods:
Let’s look at the two and see if there’s a difference. If there is, then I’ll go ahead and initiate a full retrieval, normalize that and store that in the database. But I can do that without having to have the log data act as the trip wire that initiates that retrieval. But ideally, I want to be able to do everything real time so that I’m always looking, at a dashboard that represents my real time situational awareness. So that at any given point in time, you can look at the key security performance indicators and know that that’s a true real-time reflection of what your environment looks Like. Hopefully that makes sense. You’re welcome. So let’s see here. So always looking at the log data, I talk about change detection, and these are just the ports. This is an example of how we talk to certain things. This is not complete by any means.

Tim Woods:
So let’s go ahead and switch our screens, let’s go into Google here, and let’s maximize that, so you guys can see it all here. Let’s log in again. This is actually an internal network on my PPN, one of my developers networks. So hopefully everyone can see this. So show you a few things here. And then guys, I’m going to minimize my bar over here. How do you integrate FireMon with firewall as a service, or do we monitor it from our end as a check? Firewall as a service? So in the clouds, I suspect that you’re talking about, and by all means feel free to elaborate, but I’m assuming that you’re talking about the AWS security groups or the Azure firewall, or maybe even Zscaler who we’re in talks with right now, some of those firewalls as a service.

Tim Woods:
So again, everything that we do, we try to support the Vendor API, the Vendor Publish, and I’m going to show you how we promote our own API as well. That gets a little more technical, but we can go as deep as you want to, but essentially I’m trying to always align myself with the preferred method that my technology Alliance Partner prefers how I communicate to their devices. So typically, that interaction between any type of firewall as a service or any firewall platform for that matter, we’re doing it over the Vendor supported APIs, authenticated of course, everything has to be done securely and encrypted. I hope that helps.

Tim Woods:
So when you look at the dashboard here, this is just this shows you at the very top here. The first thing that I show you, this is my KPI dashboard. If I scroll down here, you’ll see additional statistics. I’m looking at my Security Concern Index. My Security Concern Index is a baseline. It’s built up of a risk, how open or pervasive are my policies, what are the security risks involved? Do I have any clear text protocols? There’s a number of variables that go into that to create the Security Concern Index. Now don’t get too wrapped around the axle about that, but what it really does, is it gives you a baseline to know where you’re at and then where you want to go. So are the actions that I’m taking having a positive impact to the maintenance of my security infrastructure, or am I going in the opposite direction?

Tim Woods:
So, on any good report, you got to look, where am I at today? Where do I want to go? And then when I get to where I want to go, how do I stay there? Right? So, that the Security Concern Index definitely gives me a trending way of tracking that. Rules contributing to control failures. This talks about our… This is after a change happens, and I run that assessment. I can see where my control failures are at? And what those control failures are? What are my most active firewalls? What is my complexity by device? So when we think about complexity, a lot of times if we have, let’s say an in the service field, or too many in the policy, and it happens a lot, right?

Tim Woods:
We were trying to honor the speed of the business and they’re trying to… they need an application, or they needed access to an application up and running by given time. And so we put in, but they lack… they don’t give us all the necessary information. Where’s it coming from? I don’t know. Where’s it going to, I don’t know. Well, what are the protocols or the services or the applications that the application leverages? I don’t know. And so we build the best security rule possible, but it becomes, it’s allowing way more access to what the needs of the business really require, but at least we got it up and running. We’ve honored the request of the business with the intent of going back to tighten that up later, once we get some of that missing information. Unfortunately what happens is, again, I go back to my plate of priorities and that rule gets shuffled down the stack and I don’t get back to it.

Tim Woods:
Now I have this overly permissive rule buried in my policy, that’s allowing way more access. And we usually don’t discover that until something bad happens. And that’s not the time that you want to discover it. And so looking at a complexity report, I can see if I have any rules, any firewalls, or any rules or firewalls that I need to go investigate. And by the way, any of this data that you see here, any of the data that you see in the dashboard, I can quickly drill into it. So for example, this ACI, CLI tests, overly permissive. If I hit that, I go right to that device and that can start getting into the particulars. I can start getting into this discrete content of that particular enforcement point. So I can very quickly go from a very high holistic level of showing you everything holistically about your security infrastructure, but getting down to that needle in the haystack. For example, here.

Tim Woods:
God, I’d like to see all the redundant rules that are on this device. Well, let’s just click on that. Bingo! Here, I have a list of all my redundant rules that are in this particular enforcement point. It doesn’t get any easier than that from a point and click perspective. And so anyway, we can see here device inventory. This is just how many devices I’m monitoring. What’s my percentage of change. What’s my total amount over all my firewalls over all my rules, how many unused rules do I have across my entire environment? I’ll be honest. What we see typically in many of our environments, when we engage with a new customer, is many times we see… when we start looking at some of their firewalls, it’s not uncommon for us to find 30 to 40% of the rules in that firewall on it, and I’m talking about a firewall that’s been in place for more than three or four years.

Tim Woods:
Three years is not a long time for a firewall. So imagine how quickly that bloat or that stagnation mounts up over time on a firewall. And now of course, when you get into acquisitions and mergers and regulatory compliance initiatives and all the different things that are taking place right now. That even accelerates more, we’re seeing a big lift in the just the sheer volumes of rules that enterprises are responsible for managing today. And so, it’s almost mind boggling. So without something that kind of gives you visibility into that, it can be a struggle to understand what’s actually taking place in the environment. One of the things that I liked the best about the FireMon dashboard here is this little bar right up here, it’s called our omni search bar. And so I told you earlier that we integrate with elastic search.

Tim Woods:
So one of the things I can do here is very quickly. If I want to find something against all my policies, everything that I have, every firewall, every rule, every policy across everything that you’re allowing FireMon to monitor. Let’s say, Randy gave the example of RDP and RDP is, what is it? Your port three, eight, eight, nine. Let’s say I wanted to find port three, three, three, eight, nine. And I want to see if port three, three, eight, nine is used anywhere across my environment. So I just type it in there and very quickly, you’ll see here. I can see that. Yeah. I have some service objects that contain port three, three, eight, nine. And so I could go look at those, but they’re not leveraged anywhere on a firewall. However, I do have an Azure firewall here, that is leveraging port eight, eight, nine.

Tim Woods:
And if I wanted to go look at that again, I can just simply click on it. It’ll take me right to that firewall. I can see the rule, rule 101. That’s actually has that port, and I can see where the port is enabled here. And I can look at that very quickly and then I can get some more details. So that’s just a quick example of how you can get to something very quickly. But think about this, think about if the new CVE came out and there was some, high port or some malware or virus or something that was out there, and you wanted to quickly assess against all of your firewalls, against all of your rules. If you had that port in use anywhere, then I could very quickly, I could just use omni search to show me that, or I could run a standard report as well.

Tim Woods:
Okay. So, let’s think about how I group my things as well. Let’s look at what Randy was doing with… And I love that term, firewalking, I wish it wasn’t already used because that would be a cool thing to call some functionality within our tool. We can do something like firewalking. I think we do it a little bit better with a little bit more of a visual display, but with some really good solid data behind it. But I’m going to show you how we can do that. We call it access path analysis. We have device path analysis, we have access path analysis, we have risk path analysis. We have different ways that we look at the past along the firewall here, but let’s say if I want to go to hybrid network group, let’s see hybrid network group here.

Tim Woods:
I’m going to go into that. This particular zone is composed of 62 devices. Let’s go to the map. Kind of just see what that looks like here. So I can see what my hybrid networks zone. So, here you see all my zones of controls that have been illustrated across the network. Everything from my cloud to my virtual, to my transits, to my DMZs, here’s my main data center. And here’s where I get out to the internet on my external. So these are some of my external facing routers and, and bastion hosts and things like that. But let’s say, I’ll zoom in on this just a little bit and see if I can, hopefully you guys can still see this. I click on this, I’m going to create from this particular network inside my main data center. I want to go from my 10, 24, 22 network, and I want to go, where do I want to go? Let’s go out to the internet. Let’s just go to 8.8.8.8 how about that? And we’ll do it over port… We’ll do it over SSL.

Tim Woods:
So that’s all I’m going to do. I just want… rather than me using firewalk or traceroute or ping or finger or who or anything like that, SSAS. I’m just going to… I’d like to see if I can get from this network out to the internet or out to this destination on the internet. Does my policy allow it, or does my policy not allow it? So let’s go ahead and run that very quickly and let’s see what it brings back. Well, initially I can see right away that my route and my policies allow my access out to see.

Tim Woods:
I can see right away that my route and my policies allow my access out to gain access to that particular point. And then I can kind of expand on that to see, well, what does that actually look like? And so this is kind of a summation of where I started from and how I got to where it is, so all the way traffic was accepted on my Internet facing. I happen to know 19268255 is my Internet facing zone.

Tim Woods:
But if I want to get even more detail out of this, I can come over here and look at my little digital diagram. Randy did a great job of drawing these, but we draw these for you too inside the product so that you get that visual display of that tracer of that access pass that you did.

Tim Woods:
But we take it a step further. When I hit my first firewall in this case, for that particular access path analysis, I had to go through my Fortinet gateway. And I show you my ingress and my egress points. I show you any NAT policies that I hit, and I show you the rule that matched that allowed that access very quickly. I go on down here. I can see that I hit my next zone and then I hit my next firewall, which happened to be a Palo Alto. And then I can go on down and I can see that, yeah, there was NAT involved here as well. I can see which policy that it hit and I can see which rule that it hit as well.

Tim Woods:
And then if I wanted to, I could actually expand on this and actually look at the rule from here. Or if I wanted to pull that device and that rule set up in the tool itself, then I can just click on it and I’d go directly into that rule and kind of look at it, if I wanted to.

Tim Woods:
So again, very quickly going from the top down, I can kind of look at this stuff. And this is all done because we have an active real-time network depiction of your topology that I’ve developed from getting intelligence from the devices that you’re allowing me to monitor the enforcement points. So hopefully that all made sense there.

Tim Woods:
The next thing I wanted to show you, I want to show you something that’s a little more advanced. Actually, I’m going to show you that now and then we’ll go back. We got about 15 minutes left here. I’ll show you the report library very quickly just to give you an idea. There’s the Complexity Report, Current Policy. I used to use something called CP rules when I wanted to get a print out of my checkpoint firewall. Sometimes I just wanted to get a printout of the rule set itself so that I could go and show it to somebody or discuss it with a business owner, or something like that. We give you a really nice Current Policy report. You can run that. I can get all this information.

Tim Woods:
But let’s say, I just want the Security Rules. I don’t want the User Objects. I don’t want that Application Objects. I don’t want all the NAT Rules or the Interfaces and Routes and the Zones and the Object Details. So I can turn all of that off. So again, I can be as very discreet or as granular as I need to be. I can select which device I want to run that report against. Let’s say I wanted to run it against my… I don’t know. Let’s do our Palo here. We’ll pick on Palo today. I want to run it against this Palo so I can just run the report, and very quickly, I can get a printout of what that policy looks. And I can do this in a PDF, or I can do it as an HTML print out, either one. That’s kind of cool.

Tim Woods:
Let’s go back. I went back too far here. Let’s go back to the reports. Expired Rule report, Removable Rules. Where do I find the rules that are…When we talk about those unused rules in a policies, there’s redundant rules, there’s shadowed rules, there’s duplicate rules. There’s also just stagnant rules. They’re not necessarily redundant, or they’re just rules that somebody mentioned it earlier, where you have a device that’s no longer accessible. And that rule kind of went to sleep. Auditors actually call that unintended access when that rule wakes up, because somebody, as Randy pointed out, reuses an IP. And all the sudden you’re providing access to a device that you never intended to provide access to because of this rule. But I can very quickly look at an unused rule, our removable rules report. I’ll run it against my Cisco here and just very quickly show you that.

Tim Woods:
And then very quickly, we give you just a really simple rule. This policy has 20 rules, which has been identified as removable. Remove Rule 5. Well, why do we remove? Because Rule 5 is made redundant by Rule 4. And some very simple math going on here. Sometimes it’s the higher-level rule that’s providing more access. And so the desired intent is to get rid of that higher-level access and rely on more discreet rules. So it’s two ways to kind of skin that, from that perspective. But again, I’m just giving you something, very quick, that manually sometimes is very hard to derive.

Tim Woods:
And then we get on down here, PCI Reports and Device Health Reports, Device Inventory Reports, Traffic Flow Report. So one of the features that we have is a way to look at who’s talking to who across the policies and we can run what we call a Traffic Flow Report against the particular rule, and just see what kind of information is developed. So here, somebody has run a Rule Report against Rule 24 in my policy.

Tim Woods:
If you have an innie in your application zone or your service column, wouldn’t it be nice to know what’s actually going through that? Maybe I’m trying to convert a legacy policy to an application centric policy, or maybe I’m just trying to get rid of this innie and I need to understand what exactly is going across that innie so I can lock it down to just those things that I know is actually being utilized. And that’s exactly what traffic flow will do.

Tim Woods:
If I run this report very quickly, I’m looking at this Palo Alto. I can see what the connection. I can see that somebody ran this report for one day. I can see when they run it, how much information, this is the Rule 24. But very quickly, I can see my IP4 sources, IPv6 sources. I can see who’s talking to who with the flow data. And the little numbers that you see here in parentheses, these are hit counts. So I can see how active that communication is as well. And then if I go on down here… I’m going to go ahead and get to the meat because we’re running out of time… I can see all these. But I can see exactly what’s going across that service field. And I can see what’s going across the application field.

Tim Woods:
So very quickly, here we have 1, 2, 3, 4, 5, 6, 7, 8. Let’s say there’s 20, 25 different services here. Rather than having 65,000 services open, wouldn’t it be neat if I could just lock it down to those things that I know is actually being leveraged across this rule. Minus maybe some of these scan ports where you see this 1 hit, 1 hit. Those are probably somebody doing a polar scan or something like that. It doesn’t look like a functional use of the rule.

Tim Woods:
But very quickly, I could get rid of this innie and lock it down to just those things that I know are actually being used by the rule. So again, something that if you tried to do manually can be incredibly time consuming.

Tim Woods:
So very quick, in our last couple of minutes here. How does this hit the network performance-wise? A very quick question from Victor. It doesn’t. There’s no real performance network impact on the network itself. So all’s we’re doing, we’re just looking at the data coming from the devices, looking at the log data. So all the analysis that you see is kind of done offline in our environment. That’s when I’m running these simulations, when I’m doing the access path analysis, when I’m doing my risk analysis, all that stuff, it’s all done in a simulated image. So there’s absolutely zero impact to the network itself, which is kind of cool.

Tim Woods:
But I want to show you something advanced here, guys. We’re running out of time, so I want to make sure that I get two things in here to show you because we could go through this for a couple hours.

Tim Woods:
When we get into the policy section, we get into the security compliance section and the change, if we wanted starting to look at the different changes and what the changes look like and stuff like that.

Tim Woods:
But very quickly here, I want to show you… Let’s go back over to my hybrid. There’s 100 different ways that I could get to this, but I just like to use the Omnisearch here if I go into the policy here. So this is just information about all the different policies that own this particular segment. But this is something that gets a little more detailed, but it’s very cool. Let’s say I want to look at the security rules here. So these are all the security rules across my hybrid enterprise here.

Tim Woods:
But I want to add a filter to this very quickly. And that filter is I would like to look at, let’s say, I want to look at failed controls across all the firewalls and all the rules that are in this zone. And I want to look at only those failed controls that are high or critical. And again, a control is part of an assessment. A control is like a compliance check or an audit check of something that I’m looking for in. And so there can be there’s 11 different kinds and it can be anything from allowing a clear text protocol to not having a document, to a rule being unused, or looking for something that shouldn’t be there.

Tim Woods:
We ship out of the box with over 500 controls that you can use and you can basically configure it any way that you want it to look.

Tim Woods:
But here’s what I did here is I just built a quick filter. And what I really did here behind the scenes is I used my integrated query language. We call it our security information query language. And it’s an integrated part of the platform that allows me to get to that data that’s in the database, all of those rules and firewalls and routes and all that intelligence that we placed in the firewall, in the database, my query language allows me to get to that. It’s all available in the reports and you see it in the dashboards and you can point and click.

Tim Woods:
Let’s say I would like to provide some of that information to a portal, or I want to use my API, or I have another product in my network that wants to come in and consume that information over my structured API. So one of the things we can do here is we can use our security query language to build that query to get the same information that I could put out. So again, this is getting a little more detailed, guys. I’m going down into the weeds a little bit here.

Tim Woods:
But I want to show you what that query that I just did looks like. What did I do to look at all those rules? What did I do to find only the failed controls that are critical or high? What did that query look like? Well, this is what the query looked like right here. So the device group, the ID, the control status. Control status equal failed. The severity had to be 8 or greater. The severity had to be 6 or greater for high per high. So I’m just going to take a copy of this query. Now, check this out. If I go into my admin section… And for you guys that have had any dev ops experience or you’ve ever played around with APIs, you’re going to appreciate this… We expose our entire API inside the platform. So we use the open API 2.0 standard, which used to be Swagger, inside of FireMon so that you can see all of our APIs that are available.

Tim Woods:
But one of the things we were talking about the security language. So I want to see all the APIs that are available over my security query language. In fact, I want to test that security call, that query call that I just did. So let’s look at… I think this would be it… The security rule page search. So not only do I show you what those APIs look like or what it looks like, but if you want to play with the APIs and exercise those APIs, you can do that from within the platform itself.

Tim Woods:
So check this out. If I wanted to paste that query that I just did in here, and then I wanted to try it out, boom, here you go. JSON format. You see here’s the query that I made and here’s the return. So that same information, as long as the person… And most people can, most all the APIs can consume the JSON formatted information. That same information could be ingested to anybody I wanted to allow to ingest it, and very quickly over my API call. So pretty cool stuff.

Tim Woods:
Again, it gets a little more technical, but that’s how easy it is to kind of visualize the APIs. And by the way, the APIs here, if I go back into it, you’ll see, this is just the security manager API. So for the other products that I talked about later, we expose all of that. So if you wanted to look at the APIs for global policy controller, Policy Optimizer, the workflow, all of that information is in here and available. So it makes it very easy for third-party integration and for extracting information that you may want to raise the total value of your combined security solution somewhere else. So again, very cool stuff.

Tim Woods:
So in the last couple of minutes that we have here, let me go back. Guys, I know we’re running out of time here. This is a good question here. How does FireMon handle periodic firewall rule reviews? That part there is the module that I showed you earlier that’s called Policy Optimizer can allow you to review your policies on some scheduled basis. Also, if you have any control failures, I can automatically promote that failure into Policy Optimizer as a failed control ticket, and actually assign remediation control to somebody. Meaning that I can assign somebody kind of judicial responsibility to go off and fix that. So rather than just telling you that you had a failed control on a rule because somebody made a change and they changed something that doesn’t align with our compliance posture, now I’m going to assign somebody to responsibility to go and fix it. So happy to show that.

Tim Woods:
And listen guys, any of this stuff, if this resonates with you, if there’s something here that you think would be a value and you want to set up a personal demonstration of the product to go through it with your own security team, by all means, you can go to our website, you can download the product for free. We’ll give you a free 30-day license. You can try it out in your own environment. We’ll provide you technical services to help you guide that so that you can minimize any of those learning curves, get you up and running as quickly as possible. And you can evaluate it on your own production network or your test network, whatever you want to do. Or if you just want to run through kind of a personal demo so that we can interact real time, we usually set aside an hour to do that, but we can definitely do that as well. So happy to do that.

Tim Woods:
So last thing I want to show you here in the last couple of minutes that we have is I have a couple of zones that have some risk data in them. So I’m going to go to my risk 2.0 group here. I think you’ll find this kind of cool. And so I’m looking at my risk zone. Let’s go over here to what I call my risk analyzer. I don’t have a year’s worth of data here, so that isn’t populated yet. But I can see my riskiest assets. I can see some of my most common vulnerabilities that we’ve identified. I score my riskiest rule based on which ones are allowing access to some of the known vulnerabilities that are within the zones that we’ve imported the vulnerability scans against.

Tim Woods:
But one of the cool things here is if I want to actually… And I can look at the assets, I can look at the vulnerabilities, I can look at the risk map. And one of the things that I can do, let’s blow into this a little bit on our risk map, is I can actually run a test. I want to simulate an attack. So if a well-known actor, if a bad actor, a nefarious individual, a bad guy, came in through a well-known threat entry point, how far could they potentially get?

Tim Woods:
So we will actually visualize that for you on the network here to show you. The fact that it’s red, this means that they have access to a root exploit. So they’re able to bypass this firewall and potentially exploit this root exploit and potentially pivot somewhere else on the network.

Tim Woods:
So what do we do here? How else do we augment this? So one of the things that we’ll do here, in addition to showing you what that path looks like, is we’ll give you a metered recommendation. We’ll give you a recommendation for, “Hey, where can I reduce the greatest amount of risk in the least amount of time based on my analysis of this risk access that we’ve exposed here?”

Tim Woods:
So here’s the amount of risk. I want to patch 7 of my compromised assets and in doing so I will protect 733 assets. And so I can simulate that patch and see what impact it has on kind of my visual. And what we’ll see here is now it didn’t have any impact on this particular outward bound, but we can see that we’ve eliminated the exposure going further internal to my network. So hopefully that makes sense.

Tim Woods:
So guys, listen, there’s a lot of information in a very short amount of time. Love the information that Randy presented to you today. I hope you saw some value here out of how to… We understand that it’s hard, especially the more firewalls you have and the more rules you have, and sometimes the hygiene of the rule sets kind of gets a little bit out of control. We’re happy to put our arms around that for you, help you clean it up, get you in a better spot, put some monitoring in place around those, put you some dynamic compliance initiatives around that so that we can stay happy and healthy going forward. So hope that helps. Would love to entertain any questions that you have outside of the webinar. But more than anything I want to thank you for your time with us today.

Randy Franklin Smith:
Hey, just two more questions, Tim. Licensing model, what’s that based on?

Tim Woods:
It looks like per device, typically it’s per device. Now we’re very popular in the MSP space as well. So we do have an MSP license because we have very granular role-based administration and multi-tenant kind of functionality. But typically it’s licensed. There’s a flat fee for the application platform. And then it’s a per device, kind of a per firewall instance. And there’s a difference in the prices there. Whether it’s a big firewall or a little firewall or a virtual firewall or an HA firewall, which we only charge half for.

Randy Franklin Smith:
All right. Awesome.

Tim Woods:
It scales economically.

Randy Franklin Smith:
Cool. I think Kumar has got a few more questions. Maybe you can take those up with him offline, but this was a fun webinar and appreciate everybody joining us. One thing I didn’t mention, and somebody brought out, is the value of having your firewall logs as we’re going through some of these tests. Because if you’ve got the right logging turned on, you’ve got access to it and you can wade through all the other logging, that is one thing that would help you with some of those issues I was bringing up in terms of is the firewall passing the traffic, and there’s just nothing behind it. That was the only other point I wanted to cover. Hope this was valuable for everybody. Thanks for spending time with us. And Tim, you got some awesome technology there. Thanks for making today’s session possible. Have a good day everybody. And we’ll talk to you again soon.

Tim Woods:
Thanks everyone. Cheers.

Randy Franklin Smith:
Bye-bye for now.