Removing the "NO!" from innovation

On-Demand

Video Transcript

Doug Olenick:
Hello. Hello everyone, and welcome to today’s session. My name is Doug Olenick, and I am the online editor for SC Media and your moderator for this program, which is sponsored by FireMon. The topic is, Removing the “No!” from Innovation. Our speakers are FireMon’s Paul Anderson, vice president of solutioning for GPC, and Josh Williams, senior systems engineer, cloud and automation solutions. Now, before we get started, I’d like to mention one quick item. There will be a question and answer period after the presentation, so please place your questions in the space provided on your screen. And if we don’t happen to get them answered today, we will take care of it after the session is over. Now, automation of global security policy management allows security teams to have parody with the speed of business innovation. So today Paul and Josh will go over use cases for automation in policy management and how an automated global security policy management framework can help organizations leverage innovation without introducing security and compliance risk. And without any further ado, since time is short, I will roll out Paul and Josh.

Paul Anderson:
Hey, good afternoon, Doug. Thanks for the introduction. And thank you for having us. Everyone out there in the audience, thanks for joining us. My name is Paul Anderson. I’m going to take a few minutes to go over what Doug said and recap the problem. And then Josh is going to show you some use cases. So please keep the questions coming and we’ll try to get to everyone that we can. Similar to what Doug mentioned at the beginning, the majority of customers we speak to out in the field day-to-day either have a problem of scale, speed, or more likely both. So when I say scale, I’m talking about the numbers of firewalls they have in their environments, the types of firewalls they have, the number of changes that they have to handle. And just in general, not enough time or not enough skillsets across the employee base. Pressure, the growth in the problem with the pressure of speed, or combine the growth of the problem with the pressure of speed. There’s constant demand to improve SLAs, to enable innovation like you see on our title slide here, how can we go faster?

Paul Anderson:
How do we allow a development team to deploy in hours or tomorrow as opposed to weeks? Or our team has fully completed the ability to automate server provisioning, why does that server have to wait three weeks to get on the network? Combine that with new application development models and Dev and DevSecOps, or things like CICD or infrastructure as code where customers want to develop and deploy in real time. And now you have some friction and some desire to change traditional firewall management. So security management that we see day-to-day is very device by device focused. It’s very focused on rules and IP access for existing devices. Compliance is reactive on the backend. And most customers have some sort of serial workflow that moves from left to right.

Paul Anderson:
As we see customers starting to change and adopt new philosophies, we see people looking for either an application abstraction layer, or how do I manage my request more based on the intent or the purpose of the asset that needs access, as opposed to device by device rule by rule? How do I make compliance proactive? What kind of checks can I put in the front end to minimize the amount of manual work my team or minimize the amount of errors that gets through? And how do we have these actions going in parallel and create continuous compliance, as opposed to just doing manual checks on the backend?

Paul Anderson:
As I mentioned, most of our customers have some sort of left to right workflow from request to change. What we see customers starting to do is look at, what are the use cases to either get machine assistance or full automation in each of these categories, or end-to-end automation when they believe that something should be pre-approved to enable faster provisioning for certain types of requests? So in order to move to a model of continuous compliance, we believe customers need to move more towards intent, such as my web server always needs to talk to its database server. We want to take information from sources of context, what can we see from a CMDB? Or can we get data in from a threatened vulnerability management software in order to input changes? And then policy, what are your organization’s baselines for risk or compliance?

Paul Anderson:
What are the things you always approve? What are the things you would never approve? What are the things you may approve, but you want to send them over to review? And what are the baseline firewall configs that you already have in place so we know which changes need to be made as opposed to the teams and the customers trying to figure that out? So with that being said, I’m actually going to switch over and let Josh take the reins and talk through some specific use cases, as well as levers of control that customers have to solve these problems.

Josh Williams:
All right, let me get this pulled up really quick. Thanks again everyone for showing up. I want to walk through just a couple of quick concepts first. Paul talked a lot about intent and how we’re using intent, so let me boil that down for you. After I boil that down, I want to show you then how we’re able to take the intent and use it to adjust your SLAs, and in a good way, right? So adjusting to where we pull them down and allow you to speed up your security infrastructure deployment to stay abreast with the speed of deployment of your servers, like Paul just pointed out. First, let’s just look at intent, and let me explain that. When we’re talking about intent, really what we’re talking about is nothing crazy esoteric. We’re just creating this abstraction layer in which we’re able to reach down into multiple devices in your heterogeneous environment and make adjustments to the policies.

Josh Williams:
So for instance, if we were to look at this first access rule here, what we see is a source, a destination, service application, and then an action. It’s nothing new, or no new crazy concept that you’re not able to understand from a firewall administration perspective or from a perspective of a requester just needing to be able to get to specific devices. So we’re not reinventing the wheel here. All we’re doing is we’re saying, you tell us what you want to call. It could either be an object that is tagged with all of your internal devices, or it could be any variable that some other application might need. It could simply be just a service or a host or a sub-net. And then you just tell us what services and application you want to talk about.

Josh Williams:
Nothing new, nothing esoteric. We’re really just trying to provide you the common way of doing things in an abstracted layer. So let’s dive into this a little bit more, and let’s see that we have an antivirus tag here that shows you a bunch of different hosts in it. Right? So we see that there’s a bunch of different hosts that want to talk to this ASA DMZ. You can see it’s a flash 28. It wants to talk across some antivirus services that we defined earlier, and we want to allow this to happen. So I can see right now that this enforcement status is pending, so I can look and see if there’s even any rules pushed. So whenever I look, I see that there actually is. There’s a rule that’s been pushed to an ASA, and the rule’s been pushed via what we’ve defined in the rule definition.

Josh Williams:
So this has been pushed to an ASA, I’m able to get some feedback. This is actually coming from our security manager platform that FireMon has been a huge flagship product to FireMon. We have pulled this from the security manager. We’re showing this to you. But pending enforcement tells me that there’s still something left to do from the rule. So I can actually go into device changes and I can see that there’s a Palo Alto that’s also in line for this change. So for the antivirus servers to get to this DMZ, it has to cross not just an ASA, but it has to cross a Palo Alto as well. So you bring us your heterogeneous environment and we’re able to take that abstraction layer and take your intent of saying, I want to get to the antivirus server.

Josh Williams:
I want the antivirus servers to get. I could pop this open and I can look, and I can see that there is changes to be made on the Palo Alto. There’s objects to be built, and there’s a policy to be built. So this is what our intent really is. To boil it all down, when we see intent what we mean is that you give us, I want web servers or I want antivirus servers to talk to the sub-net over these services. And we find everything in your network to allow that to happen. And we precisely engage the devices and produce policy on them that will allow that specific intent to happen.

Josh Williams:
Now there’s a couple of important things to really help with SLAs. Because what we can do, when we define intent and we build intent out like that, we give you the ability to create the abstraction there. The idea of reducing SLA, we can see automatic value there. But there’s still more to it, and there’s still more to, how do we produce the guide rails to ensure that the requesters are getting prompt feedback to say that this is out of bounds of what you should be requesting? This goes against some policy that we built, or our NIST framework or PCI or whatever. We want to be able to provide that feedback to enhance the requests being denied and being modified so it can be reproduced in a fashion that will be okay with security standards and enable the functionality of the business.

Josh Williams:
Because remember, the point here is not so much that we need to increase security and lower the functionality of business, but we need security to be on speed with business requests and business functionality. So that’s where our compliance engine comes. So when we look at an access rule, we see that it’s gone through compliance and we see that it’s passed a compliance review. And I’m going to show you this really quick, and then I’ll go into the compliance engine and really show you how to. But what we see is that there was a request made. This request made this access rule. And we see that there has been an auto approval to this. So what that’s telling me is what that’s telling the user, is that when this request was made it was fast tracked through because it’s already been pre-approved.

Josh Williams:
And that’s one way in which we can speed up the SLA and the delivery of security infrastructure with the business function. So let me break this down a little bit more and talk a little bit more about compliance. So what I’m doing is I’m going through our compliance policies that we’ve got built in here. To quickly break this down, we have a global compliance and we have local compliance. When we say global compliance, what we mean is just that. Every application, or what we call an access profile that you have, NGPC, will go through this compliance. It’ll go through it once and it’ll go through our local. And then we have a post where it goes through and reviews everything again. So what we’re looking at is our global compliance, something that we set as an organization, we’re not going to allow Telnet to happen on our network.

Josh Williams:
Nobody can request Telnet. Any destination, any source, if they’re requesting TCP 23, if they’re requesting it to accept through the actions, we’re going to sell it. And we’re going to send back a message to the requester saying, we can’t allow the unencrypted protocols. This is easily fashioned towards a NIST standard, or a PCI standard, or STIG, or whatever standard you’re using. This is easily the place that you can put up the guard rails or the barriers at the very beginning stages of the request. This does a couple of things. One, it allows the prompt feedback to the requester to say, you’re in violation of this request is in violation, so you need to modify it. So there’s not a review. This takes away the need to wait for a CAB review on a Wednesday afternoon to take it back to you to tell you, hey, you need to go change this, we’re not going to allow it.

Josh Williams:
Or the SRB coming back to you and saying that. This tells you immediately that it’s out of bounds. The second thing this does is it gives a message to say, hey, these are the things that need to be modified, or these are the things that need to be adjusted. So you can quickly make a turnaround on that rule and not have to go back to a person and ask, “Hey, what needs to happen?” We give that ability for that prompt feedback and that detailed feedback for that quick turnaround on the request. So when we talk about local, what we’re talking about specifically is, how can we provide nuance and more detailed information for what is allowed for a specific access profile, or a specific application, specific department? What are we going to allow them to do?

Josh Williams:
And what are we going to either quickly allow them to get into enforcement? Or what are we going to keep them specifically from doing that we wouldn’t normally keep the rest of the organization from doing? And we can see here, for instance, that if we get a request from the antivirus server or from the antivirus profile, that requests that any of the internal PCs talked to a specific SFTP server across the TCP 22, then we pass this. So here’s how that enhances SOAs. One of the things that does, is that keeps it from having to go into a review status. Kind of like what I mentioned on the previous examples, is that tells us we don’t need to go to a CAB or an SRB. That we’ve already created a policy in our organization that says, coming from the antivirus, if anybody in the antivirus profile requests this, internal to this specific SFTP server, then allow it. Don’t send it to review, go ahead, send it to our compute engine and then enforce it across the organization. Because we pre-approve this and we don’t need to go through the process of reviewing it again.

Josh Williams:
So we provide this nuance in all the different applications that we built, for instance. So this is a list of all of our access profiles that are currently in GPC. And we’re showing that we have the ability to provide different, more nuanced access or compliance rules for those different profiles. And then lastly, what we have is global post. So this is globally going to hit everybody again. And you can see, we have, any, any that is requested over HTTP, then we need to review it. Because we understand that there’s going to be reasons that you still have to take things to the CAB, the SRB is still going to have to look over everything. And so what we want to do is we want to give you the ability to pull it out of the process.

Josh Williams:
Not deny it, not pass it, obviously. But we want you to be able to take it to the review board and say, “Hey, I need HTTP for this instance.” Right? Maybe your organization doesn’t like it, but understand it’s still around, it still needs to be used. We want to give you that ability to review it. But this helps the other two cases, the fast fail and the fast pass are able to reduce SLA time based on quick turnaround on the policies, on the compliance that you’ve built in previously and decided on as an organization, as a team, as an SRB. That you’re going to put these upfront to create the barriers during the request process. So that way you’re not having to get backend support, or you’re not having to go and sit around a table and talk about it for days trying to figure everything out.

Josh Williams:
So far, let me recap. What I’ve shown is, one, how we’re able to take intent, boil it down to figure out where to place the policies throughout your enterprise. So that takes away the idea of having to go and look at routing engines or routing tables, make sure you know where the policies goes, then go and build a policy for the different devices you have. Whether it’s a Palo Alto or an Azure MSG, or a Juniper SRX, we do all of that for you. And then two, you need to send the request through a compliance engine. And that compliance engine will either deny it based on your policy you’ve built, or it will allow it to go through based on policy you built earlier saying that we will allow specific applications to request access to these devices. So let me show off another real quick idea that we have here, and this is our profile explore.

Josh Williams:
So when you’re building out applications in your enterprise, they’re just going to have specific dependencies to them. When you’re going to want to dive in more to what they’re dependent on or what connections they already have out there. So one of the things you want to do is you want to make sure that you can see everything that’s connected to you. Now let me point out one quick thing, and you’ve probably already noticed it. When we’re looking at these, we’re not looking at firewalls and what connectivity they have. That’s not the point. What we’re really looking at here is the object and what they’re talking to, what they’re allowed to talk to. Either here, we see a deny rule that’s saying, if we quarantine it, if we tag it with a quarantine tag, nothing’s allowed to talk to it because we’ve quarantined it.

Josh Williams:
If we’re looking at the antivirus servers, we can see the flow of the intent flow. So the flow of the traffic between the two. So it’s not so much that we’re looking at net flow, but we’re just seeing what’s allowed. Not across firewalls, but across the objects in your enterprise. This really helps you get a snapshot of what your application is and all the things that it’s dependent on for its access in your organization. So while in this view, we can jump down into a little bit. We can look at the access rule and we can see what this access rule is built like. We can jump a little bit more into, and we can go back into the view that you saw earlier where we’re looking at the compliance. What compliance checks has gone through, what we’re waiting on to be pushed to the Palo Alto. So we’re able to do that.

Josh Williams:
We’re also able to go into the actual different tags and drill down into those. So we can look at the antivirus tags and see all the things tagged with it. The internal tag, we can see that there’s an addresses in here for our internal IP space. So we’re giving you the ability to take a view of the different applications you have built and see them, and to see their dependencies. To see how they’re interacting with other objects in your network. So the idea, and I think we’ve talked a bit about tags, and I just want to make sure that we’re really explaining that well. And that is exactly what you see, it’s a list of objects. It can either be, you can tag a group of objects, you can tag single hosts, you can tag submits or ranges of IP.

Josh Williams:
We give you the ability to create this dynamic object that you’re able to build objects on, tag them, and then they’re a part of that access rule. And as you can see here, I’ll just dive back into this one. We’re creating access rules based on tags. So as that dynamic object flexes with the amount of workloads that you’re producing in your environment, your security posture will flex. Because we’re not building it as IP to IP when we’re building intent, we’re just saying internal to antivirus. And then you just tell us what the internal is. You just tell us what the antivirus is. And the compliance will be built, or the enforcement will be built continuously based off the changing needs of your organization.

Josh Williams:
So let me talk one more quick idea. And that’s the idea of just how we are leveraging our APIs to produce actively and secure infrastructures that are interacting with other outside dependencies, or outside integrations. So one of the ideas we have is a very simple idea, and that’s the idea of allowing a threat hunting ability to come in and tell us that there’s a malicious IP, and that we want to deny that IP across the entire enterprise. And so what we’re doing is creating just simple access rules. And because we have access to the entire enterprise and can properly put security policies on all the different devices, then we become a really strong point of leveraging other integrations to say, hey, this is malicious. This IP we found, we want it to be contained.

Josh Williams:
Just think for an instance, let’s say your threat hunter has found a malicious IP address. And you want to kill it across the environment. You could probably say, hey, we have agents that will do specific things. But let’s say you have IOT devices. When you were bringing in IOT devices or you’re doing macro segmentation across V land, there comes an instance to where you’re not going to be able to, in specific instances, build a quarantine or a way of stopping the environment from getting to that malicious IP. So that’s what we’re able to do here. We’re able to take in objects, build them through an API, tag them through the API. And then say, now that it’s tagged with the NIST or the NAI, we are now denying it across our entire enterprise. No one in our enterprise can get to this malicious IP now.

Josh Williams:
And then later in some kind of playbook you can say, okay, now that this threat’s mitigated, untag the object. It just shows a very dynamic nature of the way we’re interacting and the way we’re able to build out policy across our infrastructure. So this is about as deep as I think I can go in this short amount of time. I really want to get into a lot more, but in the interest of time, I think I will probably stop there. I know we have some questions, so I’m going to go ahead and stop sharing, and would love to answer some questions that anybody might have.

Doug Olenick:
All right. Well, thanks for the great presentation there. And we will get to the questions. Our first one is, what role does GPC compliance play in security automation practice?

Paul Anderson:
Good question, Doug. And I’ll jump in because Josh showed a lot of how it works and different options that a customer has at their fingertips. But what the outcome is, is two-fold. One is in the category of enabling the business. The compliance review can be a bottleneck in the time from the request to the time it gets deployed. And so let’s say you have a critical service. You’ve got to spin up 100 servers for, I was going to say Black Monday or cyber Wednesday, or open enrollment for a healthcare company. And, how long does it take for that request to get through? So if we can speed up the time without compromising security, then you can have a faster SLA. So we have a lot of customers looking at GPC compliance and using it as a front end filter to minimize the amount of time they have to spend on their manual review. On the security side, that gives that compliance team more time to focus on the complicated requests to not have to cut corners or open up something they shouldn’t open up just to hit a deadline.

Paul Anderson:
It minimizes the amount of work on the backend from an audit and compliance prep, because of the amount of human errors that would have been caught or access policies that should or should not have been granted on the front end. And then we have a lot of security architecture IT sec teams that like the fact that this gives them known good, or what they call baseline configs, for those applications. And this is where the concept of continuous compliance comes in. So once we establish what those known good configs are, the engine’s going to continuously scrub those configs however often the customer wants it to. And if it finds a rogue change or something that shouldn’t be in there, it’s going to alert or pull it out. And so now you have the confidence to know that your configs for that application or whatever that service is, are consistently accurate, as opposed to just the fact that they were accurate the day that you implemented them.

Doug Olenick:
All right. Question two. How does FireMon GPC help companies address their ever-changing landscape in terms of scale and also in terms of basic security?

Paul Anderson:
Yeah, that’s a good question. And that’s a really common one. One of the things we hear the most is changing paradigms. Like, I now have firewall rules in NSX at the distributed firewall level, and I have Azure NSGs. I have more different types of environments to manage with different levels of skill or skill sets I have to train up on. So by using an abstraction layer where you have one central point of control that you enter the intent and then compute what that policy should be and where it should go, it minimizes the amount of time that these users have to spend in each of those different types of constructs. And therefore, again, ultimately supply a faster SLA or higher level of integrity of the configs back to the business. Josh, do you have anything you want to add on that?

Josh Williams:
Yeah. I would like to add that the idea is when your infrastructure is growing or your infrastructure is moving. So, I’ve been through many different data center moves where we pick up from this data center and we move over here. Or we’re forklifting a lot of our different firewall vendors and we’re going into a single one. Or, there’s all these different scenarios where it just causes a lot of pain from the administrator. It causes a lot of pain from upper levels that have to deal with just waiting for these changes to take place, because you have to model them, you have to design them. You have to understand all this stuff. What GPC is really going to help do, and what we’re looking at really doing, is creating this idea of, like Paul said, you put it in one spot, it’s abstracted, so you can rip out your underlie as much as you want.

Josh Williams:
But as long as you give us the routing ability, as long as you give us that routing table and something to configure, we’re going to make sure that your workloads, if they move, if your infrastructure grows, it doesn’t change. It doesn’t change what we do. And we’ll still build the policy for you. And we’ll still push it out across your network. Totally changes the redesign process for shifting infrastructure, especially underlie infrastructure.

Doug Olenick:
All right. I think we have time for one more quick question here. Okay. Do you see a role with FireMon in other SOC tools?

Paul Anderson:
Josh, you were talking about a couple of them. Why don’t you go ahead and take that one.

Josh Williams:
Yeah. Sorry. That was me being on mute. Common mistake. Yeah, no, absolutely. The SOC is growing, tools for security operations is growing. And there’s a lot of great ones out there. So absolutely, we have a great exposed APIs, we love leveraging those and working with others to make sure that we’re creating an environment where you can bring great information and detailed data to us so that we can help you secure your environment. I think the common phrase we keep saying is just, better together. That we find great ability to work with others and make the environment more secure. So, yeah, absolutely.

Paul Anderson:
I’ll give you… I’ll give you a use case example, Doug. So let’s say I’ve invested in a threat and vulnerability management solution and it tells me that I need to go block a bunch of IPs that are malicious. So question one is, once it alerts you, how long does it take the organization to block those IPs? And if it’s more than a very short amount of time, then we have customers patching that in via API, like Josh showed in the to where GPC can compute those changes if they approve the change upfront.

Paul Anderson:
Number two is, should I make those changes? Should I block all those IPs just because that system told me to? So we have customers where that pipes off to a team that then pushes those changes into the firewall via something like Ansible. But are they calculating the impact of those changes, or are they just pushing those changes because that was the recommendation they got from their threat and vulnerability management software? So that’s one example. There are many different types of SOC tools that we can interact with, but that is a common use case that we see popping up.

Doug Olenick:
All right, well that’s great. You guys rocking it through a ton of great info, but that’s going to have to be it for today. So our thanks to Paul and Josh for their presentation, and to FireMon for sponsoring the program. And of course, thanks to all of you for joining us today. This webcast will be available shortly at www.scmagazine.com, and that can be found under the events tab. Again, thank you all and have a great day.

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