Top 5 Risks of "Dirty" Firewalls

On-Demand

Video Transcription

Randy Franklin:
Good day, everybody, Randy Franklin Smith here. And today, we are talking about firewalls. And a lot of us have had a lot of firewalls around for a long time. They tend to get dirty over time. We’re going to explain what we mean by that. First of all, I want to really express my appreciation to FireMon for making today’s real training for free possible. I want to introduce Tim Woods. Tim, you pretty much eat, sleep and breathe firewalls.

Tim Woods:
We do. Randy, it’s part of our life and I want to thank you for the opportunity to talk to the audience today and discuss some of the challenges that I know that they’re faced with every day. We talk to both large and small organizations that are trying to meet the challenges of managing their security head-on. So, thank you, I look forward to this webinar.

Randy Franklin:
All right. So we’re going to first of all start out with just a quick small amount of background, and then we’re going to identify what these risks are of so called dirty firewalls, how to clean it up. And then this isn’t just a point in time project. Or if we really want to improve our security long-term, Tim, it shouldn’t be a point in time project. We need to, once we’re clean up to date, and secure, we got to stay that way. We got to be responsive to new requirements, new risks, new opportunities for leveraging our firewall for defense and so on.

Randy Franklin:
The other thing that we’re going to talk about is being able to achieve visibility of your entire global fleet or set of firewalls. There’s two important ways to analyze firewall configuration that we’re going to get into. We’ve got a good bit of material devoted specifically to traffic flow analysis, as opposed to access path analysis. To me that is one of the most interesting things that we’ve put together in the webinar. So let’s get started. First of all, when we say firewall, what do we really mean? Of course, we’re talking about the classic Cisco PIX Firewall or Check Point Firewall, Tim. But what else do we mean, at least in terms of what we’re talking about today when we say firewall?

Tim Woods:
You know the perimeter is green today, Randy. It’s what used to be, we thought about the firewall as this kind of thing that sat around the wall and acted kind as the bridge over the moat. There was kind of one way in, one way out. We were more worried about backdoors via dial up modems and things like that. Today, access to the network can come in so many forms, and restriction of that access, knowing where to restrict that access and how to manage the restriction of that access, and understanding the validity of that access is crucially important. And you hit the nail on the head earlier in your first slide when you talked about, it’s not a point in time type of effort. It is a continual effort. It requires vigilance, and it requires… And a lot of people because it’s overwhelming either because the firewall has become mismanaged over time. And then it becomes just an overwhelming task to go back in and clean it up or get your arms back around it.

Tim Woods:
And there’s so many other priorities that are taking precedence, they set it off to the side until something bad happens. And so the firewall can come in many shapes, form, and sizes today and understanding where those access rules exist. And where you can restrict access. And then how to visualize and manage that access is incredibly important.

Randy Franklin:
Yeah, and so just to give some examples, switches, routers, we need to consider them firewalls too for the purpose of what we’re getting into today. Especially given that companies, organizations and compliance requirements, more and more recognize the need for filtering and segmenting traffic within the network. It’s not just as you were alluding to the perimeter. So would we call wireless access points firewalls? I already said routers and switches. The way you put it when we were prepping for this Tim was something like anything with a routing table or an ACL. How did you put it?

Tim Woods:
With an access control list. That’s right. There’s so many things that have some type of restriction list or access control list that you can implement. In terms of firewall or what I’ll call security enforcement point, that would be considered a security enforcement point. It’s a place where you can put in a compensating control.

Randy Franklin:
And folks, by the way, please I just launched a poll, want to ask you a couple questions and we’ll share the results, so you can see what situation your colleagues are in. But also, please use the question window. We want any and all of your questions, but like I always say, we want all of your feedback. There’s a lot to be gained when we engage, and we’ll try to share as much of that with the audience as we can. Now let’s see here, voting. Okay, we’re coming up on 50%. Still going pretty good. The reason we’re asking this question is, the more vendors that you have, the more complicated it becomes to accomplish the task that we’re setting out in today’s webinar, Tim. Everybody’s got a slightly different format of ACLs. They have different management tools. It begins to create silos over time, right?

Tim Woods:
It does. There’s so much to… I was at RSA this year, and I was in last year as well. It’s overwhelming the number of vendors and the amount of technology that’s out there, right? And it’s not that we don’t have the technology, we definitely have more than adequate technology. And of course, it’s not even the next generation technology, it’s today’s technology or current technology. It’s just managing what we have efficiently and effectively. If we don’t use the technology that we have, then we’re not going to get the return on that security investment.

Randy Franklin:
True. So there’s some results, folks. There’s a large number that have got more than, let’s see, if I add that up really quick. We’re talking about 30, 40. Yeah, 40% have got three or more vendors involved in the types of devices we’d call firewalls. And then here’s the other thing I want to ask, given our definition of firewalls, how many firewalls do you think you’ve got on your network between firewalls and routers, switches? We don’t mean every single switch on the network, right Tim? We’re talking more about the main switches that have some kind of segmentation enforced, some kind of routing.

Tim Woods:
It’s those things that are protecting your zones, we call them zones of control. So, being a good old Texas boy we would call it, the goes-iners and the goes-outers. But, how do I want to protect the access from one zone to another zone? What’s the criticality of those zones, what resources are in those zones? What regulatory compliance initiatives are mandated within those zones? And understanding the policies and the devices that control access between those zones. So it’s really about your zones. At the end of the day, when we talk about breaking up your network, and we talk about analyzing all those different… I talk about the great perimeter and go into the cloud and SDN and all this other stuff. There’s so many aspects to it that… But at the end of the day, what you’re trying to do is understand what are your zones of control across all that real estate? How do I divide up my zones of control? And then how am I going to apply my compensating controls between those zones?

Randy Franklin:
Got you. The other thing that it comes to, there’s the results folks, if you’re interested. So the other thing that this then creates is a wildly high number of rules sometimes. Tell us quickly again, Tim, about that company. What was it 100,000 rules?

Tim Woods:
Yeah, Randy. We were talking and I had the pleasure of working with the company, actually local here in Dallas. The CIO had put forth a requirement for them to reduce the number. They were going to reduce complexity within the network. And that’s really where the gap comes in. We call it the complexity gap, but it’s the sheer number of rules. Typically, you like graphs that go up into the right but when your rules are going up into the right, and the people available to manage those rules, stay static, or in some cases actually reduces and that’s typically not a good thing. It can become overwhelming and get out of control very quickly and cause the complexity gap.

Tim Woods:
But this particular company have put forth a need if they were going to reduce their… They went forth and they identified all their redundant rules, all the technical mistakes, shadowed, redundant, overlapping, unused rules. They reduced in a period of four months, and this is unheard of, 122,000 rules. 122,000 rules across their environment, they were able to eliminate that were unnecessary. In having been at FireMon over nine years, Randy, I will tell you on the average with the enterprise customers, and we deal both small, large and have a large percentage of Fortune 1000 companies across every market vertical. On the average, we find approximately 40% or greater unused rules within a given network.

Randy Franklin:
Sorry about that. That’s amazing. Let’s start talking about that, the technical categories of risks that we find on quote unquote, dirty firewalls. First of all, just the unused rules that you talked about, there’s really kind of two types of that. There’s unused rules in general, and then outdated rules. Rules that violate compliance or other security requirements. And then we’ll talk about permissive rules. But first of all, let’s just zero in and… Go ahead.

Tim Woods:
Yeah, no, I was going to say I kind of break it down into when I think about the unused rules, there’s really two types of unused rules. I focus on each of them in the beginning of the clean-up process. Or when I’m engaged with a client to help them understand how they can get the biggest thing, the quickest, or kind of grab the low hanging fruit. You want to find those, what I call a technical mistake within a policy, and I’m talking about rules that absolutely, positively, have no purpose for being in that policy. It’s a redundant rule, there’s already another rule that’s providing the access or blocking the access above it. And that rule will just never get used, it’ll never get hit.

Tim Woods:
So you have these things called shadowed rules. Basically, a shadowed rule is a duplicate rule, but it provides the opposite action. So one may block, one may accept. And the danger with the shadowed rule is if you’re manually trying to interpret the behavior of a policy, you may find the action below. When we’re talking about thousands of rules on a policy, it’s very easy to skip over rules within the policy. But a shadowed rule can make you misinterpret the policy behavior. So you got your shadowed redundant. And then of course, we have our overlapping rules which you need to analyze to understand what’s happening. But in order to reduce or restrict overly permissive rules. And just starting in that process, looking at your technical mistake, your rules that have become dormant or static, have went to sleep, and then you’re overly permissive rules, those are the things you want to focus on.

Randy Franklin:
So for instance, maybe this rule up here is allowing traffic pattern X, and this rule down here is denying traffic pattern X, we go in, we’re like, “Hey, we need to make sure the traffic pattern X is blocked.” We go in and rescan, “Oh, yeah, there it is. There’s a rule that specifically blocks it right there. So we’re good.” And because 10,000 rows up, we missed this rule then that is a clear and present danger.

Randy Franklin:
It is a clear misinterpretation of what the policy behavior is doing. That is the very reason that I place a special emphasis on shadowed rules. I had not even thought about that. So that’s really interesting. So how do you find those, that’s interesting. To find a shadowed rule, it’s never going to get hit by traffic so if you can analyze historical traffic against your rules, then you can say, “Look, these rules are never getting hit.” Now, I would have always thought, “Okay, that’s just because that traffic doesn’t exist.” But it might not be that, it’s the traffic was allowed up above. So an unused rule isn’t just taking up space and distracting you, an unused rule can be a tip-off to a real security risk.

Tim Woods:
Absolutely. And now that you auditors… And by the way looking, when I call it the low-hanging fruit, with our product, with the FireMon, and I’ll introduce our audience to some of the things that FireMon does here later on. But one of the things that we provide as a function of our clean-up process is we try to find those redundant rules. And that’s what I call a day zero exercise. So I don’t need a long analytical study of the policy or correlation analysis, I can actually take the policy from day zero, and do an analyzation and find those technical mistakes within the policy.

Tim Woods:
Now the rules that have went to sleep, this is a rule that was in place, it’s not necessarily a technical mistake. And at some point, it was a valid rule, but for whatever reason they decommission the resource, they decommission the server, it’s just not used anymore. So it represents a hole in your firewall that doesn’t have to be there, like adding a doggie door and you don’t have a dog. It doesn’t need to be there. And so those we can find by looking at usage over time. The problem with those unused rules is that server that was decommissioned, that IP address that was assigned to that, make it reuse somewhere else. The next thing you know, this unused rule that had previously went to sleep or become dormant or stagnant, all of a sudden you reuse the IT guy or girl that decommissioned that server now uses that IP address somewhere else. And now you have the potential for unexpected access across the policy or unintended access, that the auditor is call it inadvertent access.

Tim Woods:
It happens more often than you would think. But now you’re providing access, potentially to an unidentified resource, from a security perspective that you never intended to provide access to. So that’s the one reason for not having a hole in your policy is it represents a potential for exploitation. But the other one is, you can provide inadvertent access to a resource that you never intended to provide access to.

Randy Franklin:
So here’s my kindergarten drawing of what you’re rendering artist’s conception of what you’re talking about there, Tim. The point is, I really hadn’t thought about this either, is that an outdated rule is also a risk. Again, it’s not just a distraction. It’s not just noise. By the way, there’s also a performance penalty to too many rules. That’s another thing you pointed out, right? Didn’t you, like one customer was able to quantify the CPU savings on their routers?

Tim Woods:
Absolutely. Your hardware pays you back in hardware. Firewalls are somewhat sequential in nature. Meaning that I look at rule one, then I go to rule two, I go to rule three, I go rule four. And if I’ve got a bunch of unused rules that I have to analyze. Or my highest used rule is at the bottom of the deck and let’s say that rule 9,999 is my top-hit rule, and 90% of my traffic or 70% of my traffic goes across that rule, then I’m going to have to go through the other 9,998 rules. To analyze whether I passed that are not, 70% of the time. But restricting the amount… The problem with unused rules is they grow over time.

Tim Woods:
People, what I find as I engage with our clients is most companies have some type of defined or well-defined process for getting rules into the firewall initially. But they don’t have a well-defined process for removing the rules over time. And so it’s rules go in, but they never go out type of things. Kind of like the roach motel. Yeah, the roaches go in, but they never go out. They check-in, they never check-out. Firewalls, it’s really interesting because over time, it causes as you pointed out earlier, ran into complexity growth, you get this firewall bloat, you get this complexity gap growth. It can represent all kinds of bad anomalies over time and potential for threat.

Randy Franklin:
Got it. So it’s just such a good point though, that an outdated rule, so we were punching on the firewall for some kind of protocol to reach dot 122 on our network, that server gets decommissioned. Maybe it sits there for a year that rule, who knows nothing on the end where dot 122 is but now we need a new server for a new application, completely different purpose and everything else. We need that IP address, we reuse that IP standard up and voila, there’s already a pathway to it that was never approved, was never even considered.

Tim Woods:
That’s correct. And it may be over some service, they may actually put another rule in the firewall that allows access to that new resource over a completely different port. Not realizing that there’s already another rule somewhere else in the policy that allows access to that resource over some unauthorized port or services or multiple services, and in there lives the rub, that’s the real risk.

Randy Franklin:
Let’s maybe address Seymour’s question real quick, because it’s so on point, he says, “But shadowed rules may be done by design, deny specific, but allow general networker or permit specific deny, general.” So Seymour’s saying, Tim, that there are cases where shadowed rules aren’t necessarily a configuration mistake.

Tim Woods:
No, he’s right. We call them stealth rules that we’ll put into the policies where we intentionally want to restrict. Typically, there are deny rule that goes somewhere in the policy so that if somebody does try to put something below it that allows access. What’s interesting about firewall policies is a lot of times more often than not, new access gets dropped at the bottom of the policy and not where it really contextually needs to reside, as it relates to policy behavior. Because we don’t have a good handle on what policy behavior actually looks like.

Tim Woods:
Most of the firewall vendors, we stepped into this market almost 14 years ago, to try to solve a problem. And that was one of lack of visibility by the native management tools, thinking that we probably had a good three or four year run at it, and here we are 14 years later and the problem is bigger than it’s ever been. You pointed it out earlier, or as we were looking at the poll. I was looking at that with great interest is many customers have multiple firewalls. And they don’t have this single pane of glass that kind of summarizes what’s actually going on across all of those different security enforcement points. Whether it’s the stealth rules, or the redundant rules, or the changes within the policies. Having a holistic view of those multiple firewall vendor products and policies is just so incredibly beneficial.

Randy Franklin:
By the way, I want to come back and talk later about optimizing. I’m starting to think that if you understand your security requirements and behavior well enough, given the sequential nature of firewalls, that there might be opportunities for optimization if you’re under heavy load situations, to reduce how many rules… What is the average number of rules that a packet has to go through before the firewall makes a decision about it? That’s going to be tied to not violating your security requirements, but basically putting rules closer to the top as possible, that match the lion’s share of bulk of traffic on the network. But I don’t know maybe that’s not even that big of a deal. Let’s talk about that later.

Tim Woods:
Yeah, it can be there’s what we call templates, and there’s acceleration templates and things like that. And it gets into some of the specifics of the different vendor products and how they operate. But in general, you’re looking at what rules are being used the most, which rules are being used the least? How do I stack those up if I’m looking at it from a sequential perspective?

Randy Franklin:
Got you. So next non-compliant rules. So we’re talking about stuff that doesn’t meet either internal security requirements or standards or regulatory stuff. There is a great example of what we’re talking about in terms of regulatory compliance requirements, and that is, PCI’s cardholder data network. It’s been a while since I’ve really worked with PCI but we used to call, it was specifically called the CDN, right? So that is, every component is defined by PCI, it’s every component that handles cardholder data, whether in motion or at rest. The first thing you can do to reduce your PCI compliance burden is to have a well-defined cardholder data network. But if we’ve got rules that violate that separation, obviously we’ve got a risk there. But you want to talk about some of the other situations where non-compliant rules come up, Tim?

Tim Woods:
Yeah. Over the years, the compliance requirements become a little more complicated and consume more resources almost every year. You talk about PCI, but we deal as I said, we have customers in every single market sector. And we have customers in every single market sector, because their challenges are somewhat common in nature, as you look across these. So whether it’s SOX, or Sarbanes, or PCI, or FISMA, or HIPAA, or within the healthcare industry, or it’s ISO 27,000, or they’re just code of conduct, a cyber threat, there’s all these different compliance requirements. And in their mid, companies either embrace it to be compliant as a checkbox, or they embrace it to make themselves better, to have a better security posture. I see companies embrace it both ways. And sometimes there’s a hybrid mix or meet in the middle of that as well.

Tim Woods:
But regardless, they ask all of these different compliance initiatives, it’s not a trivial exercise to become compliant. And in the early days, a lot of the compliance initiatives didn’t have teeth. What I mean by that, there were no penalties leveraged or assessed, levied or assessed, if you weren’t compliant. Nowadays though, there’s actually penalties in place and high trust is an example in the HIPAA where it’ll cost you money, PCI is a big one depending on the level of PCI and stuff. They’ll actually find you if you don’t meet these requirements. And so they’re causing the corporations… They’re trying to get the corporations to make sure they become compliant.

Randy Franklin:
But they all ask kind of some of the same things, do you have valid business certification? Are you monitoring for change? Probably the very first and foremost thing, and I’m going to steal a little bit of your thunder here, because I know you’re going to talk about it. But it’ll be a good point to reinforce. Are you monitoring for change? Is there valid business access? Is there a valid business owner? Are you documenting that? Are you reviewing your rules, they all kind of ask some of the same things.

Randy Franklin:
When you get down to the business owner and removing the rules, and we talked earlier about unused rules and getting those unused rules out, when you’re trying to go back to the business owner to determine if the access is still valid or not. That’s where I feel so bad for some of the firewall security people and the IT security folks, because they’re trying to trace back to the original justification for the access that’s being provided. And that individual is either gone. Or it’s change, or it was inherited rule from a merger or an acquisition, and they don’t have the historical data behind it. It becomes almost impossible to validate why that access is being provided in the first place, and it becomes a, yeah, mystery rules, it becomes a real big challenge.

Randy Franklin:
And this is the same scenario that we run into with certain user accounts in Active Directory, because Tim, I come from a Active Directory audit practice, kind of. We would identify these accounts, where the password hadn’t been changed in so long. And folks would say, “Well, we don’t know everywhere that account is used, or we’re afraid it’s going to break something if we change it yet we also know that account is highly privileged. lots of administrators have come and gone with knowledge of that password and so on.” They were paralyzed from cleaning things up, because of lack of visibility. It’s the same situation here, we’ve got rules. But if we don’t have visibility into at least traffic flow, then we don’t know what’s going to happen if we change it, and we’re afraid to change it. And so things are left in a insecure state, it just builds up over time.

Tim Woods:
Well, you’re right. There’s a fear that if I’m the one that removes this rule, or modifies this rule, and it has a negative impact that I don’t want to be at fault on that. And so they’re looking. So without management, it really starts at the management level of having a security practice that says, “It’s okay to remove those unused rules in the absence of documentation.” But paralysis sets in, it’s like I’m not going to be the one that gets rid of this rule and cause this service impact. And so out of fear, they leave the rule in place.

Randy Franklin:
Let’s see here. Let’s talk about permissive rules. There’s permissive source destination address. There’s permissive protocol specs too. And I know I definitely have seen both. But sometimes the rules were not overly permissive at the time. But later on, we’ve subdivided that network or maybe just started using more of that subnet and deployed a whole different type of systems behind the firewall on that same segment, or network. Where really now, what used to be okay, what used to not be permissive, it is now permissive. That’s definitely something I’ve found. But you’ve probably seen other scenarios or other root causes to why you end up with these permissive rules.

Tim Woods:
Yeah, I’ve seen that where aggregation sometimes causes overly permissive rules, or where policy mergers or business mergers, and you’re trying to merge policies and overly permissive rules result. Or sometimes where you’re trying to migrate from one firewall policy to another, from one vendor to another. And they do a literal translation rule to rule and sometimes permissive rules pop in. But moreover, where I see them occur is due to a lack of adequate business justification on the front-end.

Tim Woods:
This is where I really feel sorry, or my heart goes out for the IT security administrators and the firewall administrators, when managed doesn’t support a stricter form of good data into the workflow process. Too often business, unfortunately, tramps security. And so business will come in and say, “I need this, I need access to this application, and oh, by the way, Randy, I need it yesterday.” The firewall, IT person will go off and create the best possible rule that they can with the information they’re given, but because they don’t know source or destination. Or the actual service ports that the application is going to use, they’ll sometimes create an overly permissive rule. In order to meet the needs of the business with the honest intent of going back and tightening that rule up later, or more over restricting that rule later.

Tim Woods:
But unfortunately, in the heat of the day, in the heated battle, and priorities of the day, going back to clean that rule up usually never happens. And that overly permissive rule takes on a life of itself and gets buried within the policy and until somebody somewhere… Or it gets exploited, and then something bad happens. And then all of a sudden, they’re like, “Oh, why was that access ever allowed?” But that’s usually where they just stay.

Randy Franklin:
Seymour has a good point, says, “I find overly permissive rules are added when troubleshooting due to lack of knowledge about what ports or IPs are in use. So we got to get this working, start wide, we’ll narrow it down later, but that never comes, the narrowing down. That is just the dynamic of how work goes.”

Tim Woods:
Yeah, he makes a good point, it’s the same point that I was trying to make. Because they don’t have the information, they put in the wider rule and it allows the access. And then we rush off to the other 15 priority ones on our plate with the intent of coming back to this. But again, the frequency of coming back to it is extremely low.

Randy Franklin:
I’ve got to think about this, Michael says the advent of next-generation firewalls also have made older strictly port based rules, overly permissive as well. Oh, I totally get what he’s saying. Sure. Sure, if you’re tearing it down all the way or all the way up into the application level, you can implement a lot more restrictiveness. Like, sure, sure. Not even just which websites but even like what can you do? Okay, we’re going to let our employees look at Facebook, but we’re not going to allow them to play Facebook games. We don’t even think of that as network firewall rules. But I see where he’s going there.

Tim Woods:
Yeah, it’s an interest, we start talking about next-generation firewalls it’s in fact, I was at one of the Ignite conferences and did a webinar on a series there, a session on does next-generation firewall bring around next generation challenges and it definitely does. Today when we talk about the traditional firewall, what we’re really talking about is managing three tuples of information, right? Source, destination, service. And with the introduction of next-gen now, we’re talking about six pieces of information because it’s source, destination, service, application ID, content, ID, and user ID. So now we have to manage more pieces of information. And my question always is, if I’m not doing a good job managing three tuples of information, how am I going to get my arms around adequately managing six tuples of information? And so really has to be a well formed process of management for next-gen as well. But it brings about its own set of challenges.

Randy Franklin:
Tim, I just want you to know I love you for using the word tuple. I thought I was the only one that used that word. So yeah, just another example of permissive rules probably won’t spend a lot of time on this. But instead of being overly permissive in the source, destination IP address, we’re talking about the protocols, and we’re even getting beyond protocols with some of the discussions that we’ve had. And, Seth, I’m going to come back to your question here in a little while. So here’s another risk I just wanted to throw out there, is lack of firewall. Now I’m not talking about lack of firewall between you and the internet, I’m talking about inside the network.

Randy Franklin:
Maybe it’s even the failure to identify that there’s really two different logical zones here, that should have some separation between them. Or maybe we’ve gone virtual, and we have not separated our management network of our hypervisors from the rest of the environment. And so I’m just going to call this it’s not a dirty firewall, it’s just a lack of a firewall. A lot of times, I think we hold back from implementing more segmentation and isolation in our network, just because we know that, “Oh, man, another firewall and all these rules.” That’s a real shame. We’re completely missing the benefits of a whole layer of defense in depth. So just thought I’d throw that out there. It comes down to then how do we systematically clean up dirty firewalls.

Randy Franklin:
Let’s talk about two types of analysis, traffic flow analysis, and access path analysis. So the difference between the two from a high-level just encapsulate it. Traffic flow analysis is what is flowing on my network, whereas access path analysis is what can flow on my network? Both of these are extremely valuable. If we can answer these questions, then we’re going to be able to clean up and we’re going to be able to respond to change so much quicker and to stay cleaned up. But when we’re talking about traffic flow analysis, I know that’s something you guys do really well. So you figured out what it takes. But it’s primarily the collection, the understanding and the analysis of logs from your firewalls or how much do you use NetFlow data.

Tim Woods:
It’s a great, great question. It’s one that I’m really excited about. This is probably one of the highest used features in our product is traffic flow analysis. We have a feature that allows you to look inside these overly permissive rules to try to figure out what’s being used and what isn’t being used. We don’t use NetFlow, we purely use syslog. And we correlate that syslog, to the rules that are intact, and being used. And so what we’re looking at is if you’ve got an Any, typically, when you look at an overly permissive rule, it could be an exaggerated address space, but more often it’s the use of an AnyObject and for the audience. An AnyObject basically means exactly that. If I put in any in this service field, so firewall, you have this source destination service, I put in any in this service field, it means I’m going to allow any service, any protocol over the 65,000 plus services available.

Tim Woods:
And so what we will do is we’ll actually look inside that any. We track usage of how many hits on a rule, how many hits on an object, which services are being used, things of that nature. We’ll actually break that any down and tell you exactly what is actually being used across that any. What that allows you to do now is to determine what’s being used, and lock down everything that isn’t being used. And just lock it down to that stuff that you know is actually being leveraged across that rule. And so now then, let’s say I have 10 services that are being leveraged across that rule and I’m going to eliminate the other 60 plus thousand.

Randy Franklin:
So if we can look at what traffic is flowing across your network, and then if we can compare it to our rules, that then makes it very easy to show up outdated rules, unused rules, it also allows us to answer this without learning the hard way. What will break if I remove this rule, disallow rule? Or what will break if I add this restriction? That is just golden. If we can do what if questions without actually doing it in production, it reminds me of I brought up the analogy to old accounts in Active Directory. And sometimes we’re like, “I don’t think we used this account.” And so what was their solution? Let’s disable the account and see if anybody opens up any helpdesk tickets. Not the greatest way to do change management.

Randy Franklin:
But so being able to do this, being able to compare what is flowing on the network to rules, I think we can see how that’s absolutely critical to being able to clean it up. But also, this isn’t just about cleanup, it’s about being responsive to new requests, so that we can more quickly respond to business needs. That’s about justifying our existence, but it’s also again, about helping organization to be more nimble, right? So it’s a really big deal.

Randy Franklin:
And then have I talked about the WannaCry thing yet, Tim? I don’t think… I know we were talking about it right before so… So here’s just an example of my third bullet point, improving security and responding to new threats. Barry, you’re on line here you help out with Patch Tuesday Analysis that we do. Don’t be afraid to jump in, but as I remember it, this exploit with SMB was… The details about it were released, and we started seeing exploit examples, and then Microsoft patched it. And in past Tuesday, we said if you can’t patch right away, at least look at blocking it where you can on your network. Not every computer on your network needs to be able to communicate, believe it or not SMB with every other device on the network.

Randy Franklin:
So what if we could quickly go into a database of our firewall rules and say, if I block SMB, especially to this set of computers, what’s going to be the impact? Is that going to break anything? If we can quickly answer that, why then we can roll out defense in depth on a timely basis. And with zero date, exploits. It’s all about timing. So I don’t know, thoughts on that one, Tim?

Tim Woods:
This is a really interesting area of discussion, because what I’ve learned over the years especially in larger organizations, and sometimes in smaller where they’re outsourcing some of their technical expertise. But especially in large enterprises, you have the people that are responsible for the risk and risk analyzation, and risk assessment, and vulnerability threat and the scanning and all that. You have a group over here doing that. And then you have your infrastructure team. And then you have your firewall or your security implementation team over here, your firewall group. The problem with that is they don’t talk to each other on a on a frequent basis. And so you don’t correlate. There’s not a correlation of I’m opening up new access via the firewall, or providing new access to it via user requests. But the question that’s never asked is, when I open up this new access, does it expose me to a vulnerability? Or does it expose a vulnerability that hasn’t been patched that wasn’t previously exposed?

Tim Woods:
And then what’s the risk? What’s the acceptable risk related to that? And WannaCry kind of calls that out. It’s understanding what vulnerabilities I have on my network. If a bad actor comes in a well-known threat entry point, how far can they get and what known vulnerabilities that we know about could potentially be exploited or leveraged? Especially if those vulnerabilities… And then the severity of those vulnerabilities, you want to look at, is it a root exploit that somebody could gain control of machine or plant themselves within a machine and then pivot somewhere else on that the network. And so understanding just that correlation between known vulnerabilities on my network that haven’t been patched and what my compensating controls allow, being able to correlate the two of those can really provide some interesting data as it relates to your risk profile.

Randy Franklin:
Before I turn things over to you for a second, I just also want to talk about access path analysis. And so instead of what is flowing, what can flow on the network. So it’s a different type of what if question. This, again, requires collection, understanding, analysis of all the rules on the firewall. As opposed to the other one, the data we need is the locks. In this case, we need the rules and understanding the current state, then we can find permissive source and destination addresses.

Randy Franklin:
Because we ask, “Can these two systems communicate?” It comes back and says, “Yes, they can.” Now that saves us so much time Tim. Because we don’t have to go out there and get on to that computer and install some program. Okay, can you Secure Shell from this computer to that computer or from this segment to that segment? Without being able to ask this what if question, then we would have to go to one of those computers, oh, there’s no Secure Shell client, install that, test… It’s so time consuming, but is a test really necessary if we can analyze the rules and be sure that we’ve analyzed them correctly? Then we’re just reducing our time so much.

Tim Woods:
Yeah, it gets back into again, if one of the things that we do and again, just for very quickly to help educate the audience here. The way that we derive this information always helps to understand how we derive the information, but we monitor syslog coming from the enforcement points, all the firewalls, anything with an ACL basically. We look at that information real time. We parse that against a policy, the context of an actual policy that we know about. And we’re looking for specific things coming from that syslog data. We have a component called a data collector. This data collector looks at this information. And anytime we see a change from that data stream, from that syslog data stream, we extract hit counts and object counts. But we also look for anything that’s indicative of change. And so when we see a change, we have the credentials to log into that enforcement point, we retrieve the policy, we normalize that, put it in a database, do a comparison, differential comparison, extract deltas, and give you change reports and things like that.

Tim Woods:
We also at the time that we bring the policy, we also grab all the route intelligence. And this is where it gets really interesting because we grab the route intelligence, so we know and the more information, the more devices that we’re monitoring, the more route intelligence we get. And so we kind of know, not just about your compensating controls, but we also know what routes are available. What access paths are available, Randy, as you call them. And so now then we can sandbox proposed changes, and we can do these access paths analysis routines. I want to go from point A to point B, how do I get there? And oh, by the way, what security enforcement points are embedded along that path? And what does their compensating controls look like as it relates to what’s allowed and what isn’t allowed?

Tim Woods:
And so rather than having to do a ping, or a telnet, or an SSH, or a trace route, to try to determine my access, and how do I get from point A to point B, I can visualize this on a network map. So it becomes really efficient, time saving, and it’s a receipt pick feature within our product set.

Randy Franklin:
One thing that can happen is you realize we don’t even need to add the rule in the first place. But the other thing is just being able to again, the second time bringing this up, respond to threats more quickly because we can ask the what if questions and say, “Okay, we are safe to do this. So let’s bring this extra compensating control on today. Even though it may be weeks before we get the patch out to something like this SMB thing.” I want to take a break from my slides, turn things over to you for a little bit, Tim. And then we’ll come back with my concluding thoughts, so I’m going to make you the presenter.

Tim Woods:
Thank you very much. And likewise, Randy, jump in here as I go through here. For the sake of everybody, I’m going to go through these pretty quick. But I just wanted to introduce everybody to who FireMon is, what we do. As I said earlier, we’ve been around for a long time, we serve both small, middle, and large. We have many Fortune 50, Fortune 100, Fortune 1000 companies that rely on us, that have been long-term across almost every long-term customers across every market sector. At the end of the day, we’re a security software development company focused on helping you to increase your security posture. We do that by extracting intelligence from the enforcement points that are on your network, whether that’s a switch or router, or load balancer, predominantly firewalls is what we service the most.

Tim Woods:
Today, we support almost 50 different permutations of vendors between Check Point and Palo, and Fortinet, and Juniper and Cisco, and on and on. And probably some that you’ve never heard of, as we are international in nature between Huawei and SECUI and OnLabs and Hillstone. And there’s a number of so many different firewall brands out there, and stuff. But what we’re trying to do, we’re not trying to replace the native management tools of these vendors, we’re trying to augment and fill in the gaps and give you a common pane of glass that holistically shows you what’s going on within your security infrastructure.

Tim Woods:
And so what we’re trying to do is reduce complexity over time and reduce breach, obviously breaches, the biggest word. Trying to do. But we’re trying to make you meet the demands of the business without sacrificing security, we’re trying to help you gain compliance more efficiently without it becoming a fire drill, or a rapid weight-loss diet type of thing. And obviously give you a better security profile that hopefully you won’t get breached. Not that it’s a silver bullet, there’s no silver bullets out there in the industry. But there are some things to do your due diligence. I always kind of look at it as A, B, C. There’s the companies that do the minimal amount of security implementation. And they’re C, they’re the ones that have the windows rode down with the keys in the ignition in the cars running. And then you have somebody that’s in the middle and then some companies do overspend they would be considered A.

Tim Woods:
And depending on what access they’re wanting to gain, the bad actor or the hacker whoever’s, nefarious individual wants to gain access to, and how well-funded they are. There’s different types, we can get into that would be subject to a whole another webinar. But typically, it’s company C, that’s going to be breached more frequently than A and B, just happens. So where you can affect change and efficiency in these given areas is a good thing.

Tim Woods:
We talked about this earlier here up into the right, in the stock market a lot of times it’s good, but as it relates to the sheer number of rules that you’re trying to manage, not so good. Especially when, again, the staffing required to help you manage your security infrastructure is not increased. And so we get into this complexity gap that continues to grow. And the end result there is bad things can happen over time, potentially too. Really quick, the FireMon Security Suite, it’s a very in-depth suite. It covers multiple different areas where it’s not just compliance, we do clean up, we help you do migrations, we’re looking at compliance, we have an incredibly robust and extensible compliance and audit engine, allowing you to automatically audit your policy as change happens.

Tim Woods:
So as Randy was talking about earlier, we can actually sandbox changes, proposed changes to a firewall policy before they actually get implemented. And look for things like, “Does this change represent unacceptable risk to our environment? If we put this access in here, has it been vetted properly, as it relates to the riskiness of this new rule? Does it break some of our compliance initiatives?” We have nine different control types, we have this concept of controls and controls get put into an assessment. And you may have one control in assessment or you may have 200 controls within an assessment. But a control basically can look at any specific parameter of a policy. Whether I’m looking for usage or non-usage, or I’m looking for business owner, or I’m looking for specific documentation, a CR change or a firewall change request number or whether I’m looking for a time of day stamp or whatever it happens to be. I can literally, literally audit on almost any aspect of a policy and set that as a requirement. Either it needs to be there or it isn’t there, I’m looking for that at the time of change.

Tim Woods:
And I can also look at things like riskiness. Obviously, our standard security protocol says we do not allow any clear text protocol from the inside to the outside or from the outside of the inside or for zone A to zone B. Or I don’t allow a particular service port from point A to point B. I want to always look for that every time there’s a proposed change. I want to always audit that dynamically to say, if somebody’s trying to do something that’s incongruent with what our security policy calls out. Or it could be the opposite side, I may want to put in an audit, or a check and assessment that looks at my business continuity. This access should always be provided.

Tim Woods:
And if anybody does anything that would negate that access, or that would impact that access negatively, I want to make sure that I’m auditing for that too. So that I don’t accidentally shoot myself in the foot. And so these are things that we can look for automatically, every single time that a policy changes is implemented. It just happens automatically. And then we can alert you to those things dynamically. We can even go so far as to say, “Hey, this control failed or this audit failed, we have another product that’s called Policy Optimizer.” Policy Optimizer was created to help in the rule recertification process. But one thing it’s really good at is when a control failure takes place, we can automatically open a ticket and assign remediation responsibility directly to an individual.

Tim Woods:
So now then, not only have I alerted you, but somebody has been assigned responsibility to correct it. So it’s not just a matter of just… Right now one of the biggest problems we have in the industry today is alert saturation, so many alerts coming in. 92% of a recent survey that we helped complete in over 92% of the companies that we surveyed, get over 500 alerts a day. Over 80% of those being critical. 37% of the companies had over 10,000 alerts a month. And a high percentage of those being false positives. Invariably most of the security and incidents that we analyzed, had some form of human error involved with them as well. So being able to reduce those type of things. And so that’s exactly when we look at policy automation, we look at Internet automation, we look at extracting intelligence from the policy and the data. At end of the day, what we’re trying to do is reduce that complexity gap that we were looking at earlier, and help you to become more efficient.

Tim Woods:
I hear every single week. And in my position I should state I didn’t really state earlier my position at FireMon is I manage our security engineers, security sales engineers globally. And so I get the luxury of talking to CIOs, CISOs, firewall individuals, some of the smartest and brightest security minds on the planet, I get to talk to on a weekly basis. It’s not that they don’t know what to do, they absolutely know what to do, it’s having the time to do it. Most of the managers, the security managers tell me, “Tim, I’ve got my best people doing some of the most mundane tasks, and I need to bring them up from that.”

Randy Franklin:
I just have to echo that one right there that we need our smart analysts threat hunting, and leveraging their knowledge of the business as opposed to typing in cryptic commands at the firewall interface. The other thing is being overwhelmed by alerts, I just want to reinforce that one a lot, because so many of our folks are well familiar with SIMS and log monitoring, and you’re preaching to the converted on that one, alert saturation. That’s a great term.

Tim Woods:
It is. Just trying to figure out which of these really I need to focus on, where do I spend time and which ones can I disregard and when you get the amount of alerts that people are receiving it is really overwhelming. And there’s a lot of… And FireMon doesn’t specifically focus so much on that, there’s tons of companies that do. But when you think about where the alerts are coming from, it’s not just at the network layer, right? You’ve got the network layer, you’ve got the server layer, you’ve got the desktop layer. And there’s alerts coming from all of these different vector points. How do I sift through those in a quick, fast, efficient method, trying to find those things that really demand my time.

Tim Woods:
I’m just giving a quick… I was going to show a screenshot, but I had the tool pulled up here. So I just thought I would give everyone just a quick glimpse of one of our main screens here, one of the dashboards, but you can see here at the top. I’m looking at device complexity, we look at each of the firewalls and we look at policy complexity. When we’re looking at complexity, we are looking at how many unrestricted rules are in the policy? How many of them have potential risky services? There’s a number of different vectors that we plot out there to try to determine the complexity of a device. We look at redundant rules and unused rules and unreferenced objects and all of this information. And all of this can be… But this is looking at the entire firewall security real estate from a top down.

Tim Woods:
So security teams can use this information to say, are the security policies that I’m taking… Are the security measures that I’m taking, are they having a positive impact overall on the overall security posture of my organization or not? And all of this information can be drilled into… Any of this information, I can drill down into to get the underlying data, all the way down to the specific rule, to the specific firewall, to the specific object if I need to. But anyway, I just wanted to share that very quickly. I thought that was… Rather than show you a minimized screenshot here, you can look at it, and it’s divided by the dashboard.

Tim Woods:
Recently changed devices rule search, this is real interesting, we have something called Omnisearch within our… Up here at the top, I can just type in anything that I want. And Omnisearch you don’t have to use a structured query language or anything like that. It’s just a native natural language search. But if I want to look for an IP address, or an object name, or a rule name, or anything within that plot, the constructs of that policy, I can do that very quickly. And so if I wanted to find all rules that had port XYZ open, some high port open on it very quickly across every firewall, every rule within my entire real estate, I could do that very quickly. So it allows me to find things across my entire firewall real estate very quickly, which is interesting.

Randy Franklin:
Tim, can I ask a couple questions from audience?

Tim Woods:
Yes, you can.

Randy Franklin:
Okay. So Seymour says, “Please address US federal policy focus.” So he says, “Federal agencies have a list of requirements, CIS, stuff from the NIST special publications, maybe DISA. They’re kind of becoming somewhat standard checklists. So, do you run into that kind of question? Do you have assets to help folks tie what you do to those requirements?

Tim Woods:
We do. We have DISA STIGs. When we look at our reports, I don’t know if I can minimize this here. Let me move this out of the way right quick. When I look at my different reports, and assessment controls and stuff, some of these were allowed to ship out of the box with the products. Some of the other ones, some of the DISA STIGs, and NIST requirements and things like that, if you’re a government entity, then we can ship you those because they’re registered or they’re restricted in what we can provide and stuff like that. So we have an entire federal practice. We deal not only across the major branches of the service, but we have an entire team just dedicated to the intelligence community as well. And so we have a lot of out of the box federal compliance initiatives and reports and STIGs and things like that. So hopefully that answers the question. Some of it I can talk about, some of it I can’t. But yeah, we have a big federal practice.

Randy Franklin:
Got you. Seth asks, “Any suggestions for managing rules, which are rarely maybe like less than 10 times a year used, but the business demands that they’d be left on so they don’t have to request them to be opened when they need them?”

Tim Woods:
Yeah, that’s a good question. I think it comes back to documentation. One of the areas that I find lacking in most policies in enterprises is documentation or the lack thereof. And so being able to document… I see it also, Seth, I see it also in retail, where we have infrequent rules, seasonal rules, or otherwise, or business recovery rules or disaster recovery rules that are on there, and they’re only used… But being able to document, and this is for being able to place one of the things that FireMon does and does well is, and again, I’ll digress just a little bit here and talk about how we normalize a policy. When we bring a policy in, regardless of the vendor, we go through a process called normalization. What I mean by normalization is I apply a schema into this policy.

Tim Woods:
And so that I store that in a common format in my database, so it doesn’t matter whether it’s coming in from Palo or Check Point or Cisco or Fortinet or whoever. Once I get it in my database, they all comply to a standard format, and therefore I don’t have to have, as I told you, as I said earlier I have 50 different permutations of different vendor products that I support. But because I normalize these policies in place within a common database, I only have to have one analytical engine, one correlation engine. I don’t have to have 50. And so we’re very efficient in that respect.

Tim Woods:
But also, we’re big believer in placing contextual documentation where it belongs. And that’s with the policy. So once we put this into the database, we also place textual documentation into the policy. And so for these non-frequent used rules, I can document them as such. I provide all of the compliance documentation also, we put that into the database. And so whether it’s the business owner, the business justification, when it was reviewed, when it was last reviewed, when it’ll be next reviewed all this key compliance information is placed in the context of the policy itself.

Tim Woods:
But also anything that could be pertinent to the frequency of the rule use and how often that rule has to be used. More importantly, to make sure that somebody doesn’t go in and accidentally delete it. “Hey, this thing hasn’t been hit in nine months, I’m going to get rid of it.” No, no, no, no, no, that’s my disaster recovery rule. Don’t do that. But if I have the documentation that calls that out, and/or I can run a report against it, then that becomes critically important.

Randy Franklin:
Jeff asks, “Does FireMon cover host-based firewalls like Windows Firewall?”

Tim Woods:
We do not. We unfortunately do not, we play primarily at the network layer. One of the areas that we are focused on currently is, of course, with the acceleration of DevOps and SDN and the growth of SDN virtualization in the cloud. We’re very focused on cloud security innovation right now.

Randy Franklin:
Okay. Seymour is wondering, maybe this is something we could follow up on later, looking for competitive analysis reviews, comparisons, and so on. So we’ll come back to that maybe after the webinar. Kenneth asked, “Would this include the DISA PPSM program?” Don’t tell us anything you have to kill us for afterwards.

Tim Woods:
I would take that offline, I’d be happy to talk to him when we do a follow up with that. It would be really good for him to talk to our federal team, and they can talk about some of our federal initiatives. I think he would find quite enlightening.

Randy Franklin:
Great. You’ve got some great visualizations here. Hey, if you have the opportunity to show folks how you can ask some of those questions or just what does traffic pattern analysis or access path analysis look like?

Tim Woods:
Yeah, this is some of the screenshots that I’ve just taken here to show where we can simulate an attack point. Typically, we’re looking from an internal, I mean, from an external. Somebody trying to come in a well-known threat entry point, like a DMZ. And what we’re trying to do is based off our knowledge of the compensating controls, based off our knowledge of the route intelligence, we actually suck in the vulnerability scan data from someone like Nessus, or Qualis, or Rapid 7. And then we correlate all that together, we correlate the firewall rules to the route to what’s allowed in the access pass and the vulnerabilities that exist and the severity of the vulnerabilities and things like that.

Tim Woods:
And then we can do what we call this risk threat vectoring. We can also just do some very simple without doing the vectoring, or the route intelligence assessment. We can also just look at things like very simple questions like, “Here’s my vulnerability list, do I have any…” So rather than having to do it discreetly, or sequentially, or manually which we can help do to very quickly using the Omnisearch feature that I showed you. Trying to find out if I have a port exposed to a particular vulnerability. WannaCry is a good example of that, looking at some of those higher level ports that it exploited. What if I could do that automatically for you across all policies across all the rules, just to give you that list right up front to say, “Hey, these are things that you might want to go check out across these firewalls.”

Tim Woods:
So again, it all gets back… I like to say, I’m trying to sell you time in a bottle, but I’m trying to give you back time in your day, I’m trying to give you back these things that are manually involved and that can eat up a lot of your time. If I can automate those things. If I’m not adding resources, what do I do? I want to turn to automation. I want to try to automate those things that eat up a lot of my time, so it gives me back time in my day. That’s one of the things that we do with our solution suite. But definitely well-known or a threat actor, or a bad actor comes in a well-known threat entry point, how far can they get? What could they potentially leverage or potentially exploit? And I could do this internally too. I can launch an attack from the internal, from the outside to the inside, from one zone to another zone. Just to try to test my perimeters of defense and my measures of defense on what’s accessible.

Tim Woods:
But at the end of the day, what I’m trying to determine is where can I reduce the greatest amount of risk, in the least amount of time? It’s not necessarily patching, and patching and repatching that high value access. It may be patching one asset or one access control point, at a higher point of the network that blocks the known vulnerability access to those higher level assets down below. So where can I reduce the greatest amount of risk in the least amount of time? We don’t have unlimited time, we have a finite amount of time, how am I going to spend that time most effectively and most useful, that represents the biggest security plus to my posture?

Tim Woods:
So, FireMon is all about intelligent security management, giving you that single pane of glass, trying to reduce complexity across your network. These are some of the different areas that we delve into. I’m just calling out the products here right quickly. Security manager’s our core product, we have policy planner, policy optimizer, risk analyzer. Immediate insight is our threat hunting real-time data analytics tool. Basically, I can take any piece of unstructured data, throw it into a data lake, and I’ll do automatic correlation frequency of occurrence. And I can use a natural language search to find things that I may be looking for. I could use this as a front into a SIM as an augmentation to my SIM. Get away from some of the structured query language that some of the products require, but this is for rapid incident response if it’s needed. Brilliant piece of software technology.

Tim Woods:
Where a customer’s using us today. Obviously, within policy, they’re trying to clean up their policy. Migration, we see a big move toward next-generation firewalls a lot of times. You want to make sure that you clean those policies up, before you’re trying to translate 50% of your rules that you don’t have to translate. Because that can get really expensive, especially if you brought on outside resources to help you in that migration process. That can be a very expensive proposition. So we’re trying to help you automate that processes as well. Lots of different things there.

Tim Woods:
I want to just to call out very quickly one of this slide here, one of the things that I truly believe in is complexity in the network goes up, the probability of human error goes up with it exponentially. What I wanted to call out here is just give everyone kind of a picture of what the deployment might look like, from a FireMon perspective. We have data collectors, application servers, a database, all this goes into the network. We don’t charge for the data collectors. There’s no license involved there. So there’s a profitability stave here, not just for the small business, but both for the large. We scale to incredibly high levels. Or we can implement whether you’ve got five firewalls, or you’ve got… Our largest account today, I think has approximately fifteen thousand. And so we can scale to those type of levels.

Tim Woods:
So I’d love to talk to everybody on how we could help you specifically for your specific use cases. Well, if what I’ve talked about today here interests you. So Randy, I’ll give it back to you. And again, I want to thank the audience for their time today.

Randy Franklin:
All right, awesome. So I want to just provide some concluding thoughts. It’s that network security and firewall management really requires a global view and analysis of not just the configuration of firewalls, but also the logs. The logs are so valuable on the firewalls aside from detecting change, or detecting somebody breaking into the firewall. That’s what I’ve thought about in the past. But that is a wealth of information for being able to mine that for what is flowing on our network right now and being able to correlate that back to the rules. We need that that visibility and analysis regardless of how many firewalls we’ve got and how many vendors. We already talked about this, that firewall management has some interesting parallels to entitlement management. Rules, a lot of the more specialized rules. They need to be tied to a business contact and somebody who can justify the rules continued existence, and also attest that the rule is still correct. That things haven’t changed, and therefore the rules should change.

Randy Franklin:
And speaking of change, we got to embrace it, we got to be flexible, we got to be responsive. But what I’ve really gotten from looking at this is that the firewall environment tends to be broken up and fragmented. There’s different teams in different areas managing it, it’s heterogeneous. There’s no bird’s-eye view, or that single pane of glass. That all then leads to making us afraid to change things, slow to respond to new business needs, people get frustrated, because it takes a month, two months to get a change made to the firewall. We’re reluctant or never even think about, “Wow, we could use our internal routers to respond to this new zero-day threat.” It’s not truth, every zero-day threat. But there’s a lot out there because especially protocol-level filtering, if we can get very granular at the port, or you were calling it service level, Tim. Then we can really reduce the attack surface that is exposed on systems that might otherwise be vulnerable.

Randy Franklin:
So some things to think about is how often do you change your firewall? When you do make a change to your firewall, how often does that result in some kind of untoward impact and not necessarily something breaking, but the initial change did not accomplish what you were trying to accomplish? The traffic can still flow or the traffic is still restricted. We’d love to hear from you on that. Do you perceive that to be an issue? If you had to guess what would the percentage be of times that we make a material change to the firewall, we have to come back and follow up on it. That’s what we mean by impact.

Randy Franklin:
There’s also a lot of modern trends that are driving the change too, Internet of Things. When we realize, “Man, we’ve got more and more IoT devices on the network and look how they can be exploited.” So we have pressure on us to make changes to deal with that. Then there’s always mergers and acquisitions that’s always changing your network BYOD. We’ve got these less trusted devices that we’re forced to allow users to bring in. Of course, advanced persistent threats, the APTs, Tim, are to me one of the most driving needs for this in that the bad guys are going to get in to end user workstations. That is just going to happen, unfortunately, for the foreseeable future.

Randy Franklin:
So once they get in there, do we have to make it just like traveling in the US where I can drive from any address to any address in the US. As long as it’s a private civil address, and no one’s going to… Chances are no one is going to check my ID anywhere along the way, right? But that’s not how… Networks are not about freedom, right Tim? So, if we had more checkpoints in there, and more segmentation then that would really slow down the progression and lateral movement of advanced persistent actors.

Tim Woods:
So once you detect it, right? But it’s all about detecting that anomaly. And then segmenting as quickly as possible. You’re right.

Randy Franklin:
Yeah. It’d also be interesting, think about this, has it come up that, man, we really should segment our network, but we can’t hold you back. We just tend to see paralysis or moving really, really slow. And that’s, I think that’s where you guys have really come up with something that helps out with that. It brings me to a couple other questions, Tim. Carl asks, “Can FireMon perform offline policy configuration reviews?” He’s got a specific firewall in mind, the Check Point R80.

Tim Woods:
I’m sorry Randy. Say that again, was it already asking for our supportive already?

Randy Franklin:
Yeah, that and do you have the ability to perform what he’s calling offline policy configuration reviews?

Tim Woods:
Yes. You can definitely do offline policy configuration reviews and look at the current policy reports and things like that. We do support R80, we just released our second release of R80. I believe it… And you’re going to catch me here because I believe it was the R80 release 10, or the release 11. I forget. But we’ve been an Ops set partner with Check Point for the last 12 years, if not longer. And all of our technology partners such as Juniper or J partner, we’re a Cisco partner, we’re a Palo partner, part of their technology evolution process and all of them. So we want to make sure that we’re supporting our technology vendors in accordance with the way that they want us to support them and help them. Especially as we get into this next era of policy automation and policy push, policy implementation, policy validation and things like that.

Tim Woods:
We’ve never been a proponent of reverse engineering, or trying to hack our way through vendor support. We want to make sure that we’re doing it in the constructs of what either their API’s, or their requirements call for. So we want to be a really good… We don’t just want to be a technology partner, we want to be a very good technology partner in support of their advances. And so what that means is sharing information with one another on changes as changes happen.

Randy Franklin:
Tim, Steven asks, “What about support for hypervisor type firewall controls like VMware and NSX?”

Tim Woods:
Yes, definitely we’re VMware partner as well. So one of the things that we do and I’ll take just a couple minutes to or just a second to explain this. Our primary code stream for FireMon policy planner, policy optimizer, all of them, we don’t have to touch that when we add new device support. We do have support for NSX today. We’re a VMware partner. We add devices via a device pack strategy. What we mean is we can develop enhanced functionality or new device support via device pack strategy, and simply you upload that device pack to the core product, and you inherit that functionality without having to change or upgrade the core code.

Tim Woods:
And that’s how we go about purposing that. But definitely, yeah, it’s a big one, right? As we look at support for AWS, we look at support for Azure, we look at support for VMware, all of those things as I talked about our cloud initiatives earlier. Those are all part of that and things that we support today. We even acquired some cloud technology if you do a little research on FireMon, you’ll see that we acquired a company shortly ago called 40Cloud. Which helps us to augment some of that expertise in those arenas as well.

Randy Franklin:
Well, great. If folks are interested in this, with your architecture, it’s not like you’re installing agents in all these firewalls. I’m anticipating that they could arrange a proof of concept or whatever, and probably really get some valuable feedback very quickly.

Tim Woods:
Absolutely. They can obviously, at firemon.com hit our website there, they can request a demonstration of the product. We allow 30-day evaluations. I have technical expertise on hands to help them stand up the solution and see what data, help it point us at your dirtiest firewall and let’s see what the data prevails. What the data provides. Hopefully, I can help you clean something up in the process. But one of the best ways to extract the value or see the value out of the solution is just to analyze your own data. But definitely, come check us out, firemon.com. Very easy. We try to make the whole process as simple and as efficient as possible for your evaluating and maybe you don’t have… Maybe it’s not on the budget right now. But we have tons of other collateral. We have videos and we have documentation and all kinds of things you can view to help you build your business case if you want to look at us in the future.

Randy Franklin:
Folks, thanks a lot for your time today. We hope this was valuable to you. We’ll be sending out a link to the recording and other collateral. Have a great day and we’ll be in touch again soon. Bye-bye.

Read more

Get 90% Better. See How to Get:

  • 90% EFFICIENCY GAIN by automating firewall support operations
  • 90%+ FASTER time to globally block malicious actors to a new line
  • 90% REDUCTION in FTE hours to implement firewalls

SCHEDULE A DEMO