Top 9 Network Security Vulnerabilities Common to the Cloud

On-Demand

Video Transcription

Randy Franklin Smith:
Good day everybody, Randy Franklin Smith here. Today, we’re talking about the cloud and some common network security vulnerabilities that are kind of coalescing around hybrid cloud and especially applications and hybrid migrations to the cloud. I think you’ll find this pretty interesting and it’s quite evidence-based given countless security incident reports and exploits and discoveries that I’ve based this on. I’m also super interested to have your feedback if you’re seeing similar things or if you have any kind of feedback, thoughts, ideas, questions or whatever to share, please use the question window and get that to us and we’ll work as much of that in as we can. Now today’s real training for free is made possible by FireMon and I’ve got Josh Williams with me here. Josh, just take a moment and say hi if you want. Want to thank you and the folks at FireMon for making this possible today.

Josh Williams:
Yeah. Randy, thank you. I appreciate it. And I appreciate being here to just kind of talk through what we find is some very common cloud vulnerabilities for a lot of people right now. So I appreciate it. Thanks for the time.

Randy Franklin Smith:
And folks, FireMon makes really cool software that allows you to pull in the policy and the configuration and the rules from your firewalls all over the world, whether it’s on-prem network or the cloud. And we’re not talking about just like checkpoint firewalls, we’re talking about everything that has an ACL basically. And as such, they’ve got a really good view on network security. And Josh, I mean, you just got off the phone with a customer today before the webinar, so you’ve no doubt got … well, not no doubt. I know from talking to you in preparation for this session, you’ve got a good insight into things that customers are facing. So if you’ve got some good color commentary, please share it during my slides as well.

Josh Williams:
Absolutely.

Randy Franklin Smith:
Okay. So here’s the areas that I’m going to be talking about the vulnerabilities. The first one almost seems like a gimme, but the bad guys don’t care if your vulnerability is … they don’t discriminate against easy vulnerabilities. In fact, they love easy vulnerabilities and we’re going to talk about remote administration of cloud VMs being exposed to the internet. Also storage resources, being exposed to the internet, unprotected second tier services especially microservices, container and orchestration infrastructure, then misconfiguration of … It’s not like the cloud doesn’t come with network security controls, but misconfiguration or lack of configuration of them at all is a major thing. And Josh, that is history repeating itself, right? Because the number one security problem with vulnerabilities is not exploits or things that need to be patched on firewalls, but simply misconfiguration, right?

Josh Williams:
Oh, absolutely. Yeah. Misconfigurations aren’t something new to the cloud. It’s just going into the cloud and expanding our, what we like to call the IT sprawl and expanding our environments. It just enhances our ability or just creates an environment where we can create more misconfigurations. And it’s not due to just people being bad at what they do, it’s just a natural human ability. I can mess up anything and sometimes it’s a fat finger. Sometimes it’s just the planning, we didn’t have all the information for the planning. So you’re absolutely right. It’s not anything new. It’s something that we have carried over from our on-prem environment into the cloud and it’s just due to humanity.

Randy Franklin Smith:
Yeah. Larry asked a great question. I want to entertain right now at the beginning. He says, “Can you map the mistakes and vulnerabilities against the MITRE attack framework, especially the cloud matrix?” So Larry, not right now because the cloud matrix is still fairly new and not immature, but it’s still pretty skinny is the best way to put it. And I just did a webinar on the cloud matrix. And a lot of the stuff that we’re talking about today just is not contemplated by the cloud matrix. Also, we are not looking at so much attack techniques as we are vulnerabilities and attack really shows attack techniques and mitigations.

Randy Franklin Smith:
Now, I would think that you could probably map our recommendations at the end to a lot of the mitigations, but most of those mitigations would not be cloud specific. Okay. So let’s see, beyond that, another big one is lack of understanding of complex cloud resource interaction. I have a awesome example of that from the real world to show you. And then just the whole thing of maintaining compliance and being able to document and show evidence that you’re compliant. Okay.

Randy Franklin Smith:
Now let’s start with virtual machine remote administration. So stand up a virtual machine in any cloud and by default, it’s basically out there with an IP address open to secure shell or remote desktop, depending upon whether it’s Linux or Unix. Now, is that dangerous? That is absolutely dangerous. Let’s just talk about remote desktop for a second. It’s not been very long since we had a webinar about BlueKeep and DejaBlue. These were vulnerabilities that were discovered inside the remote desktop protocol. And the attack occurred here in the session set up phase. If you look a little bit deeper, you’ll notice that the attack occurs before authentication begins. So the attack occurs before authentication begins. If it’s successful, then the code runs here in the kernel drivers associated with remote desktop.

Randy Franklin Smith:
So what that means is every single one of these cloud virtual machines, and for that matter, any other Windows system out there with 3389 open to the world was immediately vulnerable. And this is a recurring theme folks. I’m interested in your thoughts on this and also yours Josh. But the cloud, when we just follow the course of least resistance, we just stand up a resource in the cloud and start using it, it’s basically hanging every last thing out there on the internet, whether it’s storage or an instance or anything else. You have to put forth effort and you have to specifically design into your cloud implementations any layers of network security defense and I think that that is a major disconnect going on. It’s like saying, “You know what, when we deploy our corporate network, let’s just get a sub-net from the internet and just make our corporate network an extension of the internet. And we’re just going to implement security on every individual device.” Josh, you hear what I’m saying?

Josh Williams:
Yeah, no, absolutely. Yeah, no and let me kind of take it back to something you just originally said is when you look at this graph and this is the way the attack happens, you said it, 3389 if that’s open, that’s going to start all of this. If that wasn’t open, if we weren’t already talking RDP to them, then this could be easily mitigated. So you’re absolutely correct. When we go into the cloud, when we’re building up new assets, new VMs in the cloud, one of the main things we’re looking at is public IPs. How easy it is to put a public IP on the internet or how easy it is for organizations to say, “Oh, we’re just going to get to everything through the internet.” Well, I mean, fine I guess, but at the end of the day, what you’re doing is you’re exposing, so your attack vectors grow, your exposure is growing.

Josh Williams:
And that creates an environment to where the smallest oversight, the smallest misconfiguration creates just this huge catastrophe or potential for a huge catastrophe due to just something small being opened up as in this case, RDP. So it’s very important when you’re looking and you know what VNets and the VMs that they’re a part of or the VNets that the VMs are a part of that they have the appropriate network defense on them to ensure that this could even start, this could even happen in the beginning. So absolutely. You’re absolutely correct.

Randy Franklin Smith:
Thanks. And yeah, I could go on my soapbox more, but I’ll refrain at least for now. The bottom line is here on this one particular point is we have got to start making an effort to catalog all of the virtual networks and virtual machines or instances that we have in the cloud. And that can be a challenge because I bet you most companies out there, well, I know for a fact that companies out there have got scores and maybe hundreds, even thousands of accounts in the cloud and different clouds. I mean, my little company, we have two different tenants and three different subscriptions on each one of those and it’s a little bit hard for us even to keep up with and these things multiply like rabbits. So anyway, I don’t want to get ahead of myself because this is a recurring theme.

Randy Franklin Smith:
Bottom line is know your virtual machines and how they are connected to the … how is remote administrative access provided for them. There are good and appropriate ways to do that and I’ve done webinars on that in the past, how best, and there’s credited a few different options, whether it be using a bastion service that’s designed for this or putting things behind something like a remote desktop gateway, using a privileged session management, or just putting these VMs on a VNet that is connected back via express route or a VPN to your own corporate network, and then reusing the existing privileged session management technology solutions or methods and procedures that you already have in place. But then that requires you to connect these firewalls and VNets up together, Josh.

Josh Williams:
Yeah, absolutely. And just, I think we can summarize this up with you can’t secure what you don’t know. Right? I mean, you just have to understand-

Randy Franklin Smith:
Yeah, that’s a good place to start right there.

Josh Williams:
Well, I mean, yeah, you just have to know. So having that catalog knowing, because here becomes the hard part is you have all these different accounts or subscriptions or from whatever flavor of cloud you’re using. You need to be able to see what all is in those different accounts or subscriptions. You need to be able to see your assets and your VNets. If you don’t know what you have out there, then how do you know what you’re going to secure? How do you know how to make it better?

Randy Franklin Smith:
And what you have out there changes not just day to day, but hour to hour. All right.

Josh Williams:
Yeah. The frequency is high. Yeah. Sorry, I don’t want to belabor the point, but you’re absolutely on with it.

Randy Franklin Smith:
So here’s the other thing that I’ve been seeing over and over and over again in the past several months, and that is unprotected second tier services. So web developers are standing up cloud instances and deploying technology like crazy. Technologies like Redis, forecaching and elastic search, fore search of course and MongoDB. That’s just three examples so that you have some idea what I’m talking about. And then they’re building applications now instead of as a big monolithic waterfall approach, they’re building them comprised of microservices, second tier microservices. But over and over again, I’m seeing that these what I call second tier resources, second tier services are directly accessible, directly addressable. Maybe that’s the better term, addressable, from the internet either via URL or IP address. And again, that’s crazy and it really boils down to the same concept as with RDP.

Randy Franklin Smith:
We can’t hang everything, connect everything onto the internet and expect to survive. There’s a great excerpt from an O’Reilly book that talks about unprotected microservices that I reference there. But the bottom line is, and to me, this seems so elementary and basic that I kind of have a hard time understanding why this was happening so much, but I just think it’s because we have a bunch of web application developers standing stuff up in the cloud themselves, and that there’s just the classic thing of running headlong into new technology without thinking about security, because it’s like we’ve learned these lessons over and over again. You very carefully publish access to your front facing web application and then this other stuff is only then accessible from your web application. And that doesn’t address all security vulnerabilities because of course, if we’re able to compromise the web application server cluster, why then we can directly address these other microservices or second tier services here.

Randy Franklin Smith:
But for God’s sake, why are they accessible from the internet? And that’s all I’ve got to say on that. Harry says CSPs make it easy to, cloud service providers yeah, make it easy to start up and don’t force a focus on security, just fast provisioning and startup. And you’re right Harry. It’s got to just be what it is. Get stuff out there, get it functional. We’re agile, we’re agile and we’ll worry about this later and later never comes, but it’s amazing how history repeats itself. Greg, many people not sys admins just … Oh yeah, yeah. You’re right Greg. Many people just assume the cloud is secure by default and you’re right. You’re like, “Well, this is in the cloud. So they’re doing monitoring and they’re doing … they’ve applied a magic security box to protect my MongoDB that I’ve stood up in the cloud.” But it’s so different than that.

Randy Franklin Smith:
Okay. Here’s another one, storage resources exposed to the internet. And this one is just as fundamental as remote administrative access. I have seen this repeated so many times and what blows me away is the security analyses and the reports don’t highlight this. Like one of them said, “Oh, and after the storage account key was compromised, then people were able to … the bad guy was able to download that whole S3 bucket and hey, it wasn’t encrypted.” Okay. Encryption is nice but again, Josh, why can’t any end point on the internet access or address that storage bucket in the first place when that storage bucket had data that was in a proprietary format only for access by the web application itself? It’s not like this was something that was being made available to lots of different applications or other services that you would need network access to. So it amazes me. People are like, “Oh, that data should have been encrypted.” No. Why is it on the internet in the first place?

Josh Williams:
No, exactly. I mean, and kind of going back to some of the comments we’re seeing, it’s absolutely right. Like everybody just believes, okay, I guess I can attach the storage to this database and everything’s magically secure. Right? Well, I mean, it’s not, so there is a bit of initial security that comes with it, but as the business grows and as new projects come up, well, that doesn’t happen. I mean, that needs to be kept up with. And so yeah, you have storage with unencrypted data attached to some RDS or some instance out there. Well, what you need to know is one that makes sure that nobody can get to it on the network, but then there’s also just risk mitigation through other attack vectors that you need to know, through scans and everything like that, that how can you exploit this not just through the network?

Josh Williams:
So we want to be able to gather and glean that information and then keep it low key, keep it down and lower the risk as much as possible. But I mean, ultimately it comes back to why was this exposed on the internet in the first place? Beyond the key exposure on GitHub, why did we have this open where they had a straight line to our storage, to a server with this important information attached to it in storage?

Randy Franklin Smith:
And you know what’s occurring to me is maybe folks just don’t realize that that’s not necessary. You can use Amazon S3 storage, you can use Azure storage accounts. So you can use cloud storage without it being addressable from just everybody on the network. I’m sorry, on the internet. And the way you do that is through virtual networks service end points. That’s what they’re called in Azure. Anyway, they have other names in other, yeah, like in AWS I think they’re called VPC endpoints. But the idea here is you are taking a storage account and you turn off internet addressability to that storage account. It’s just a bit you flip on the storage account or whatever it’s called the S3 bucket and then you explicitly state that this cloud resource is available from the following virtual networks in your cloud tenant.

Randy Franklin Smith:
Another way to do it is a little bit newer feature from Azure called private link. And I guess it’s called the same thing on AWS, interestingly. But these are both ways to say, “Okay, I’m going to use the cloud, but besides just keeping my storage account key secure, and that being the only thing between everybody out there on the internet and my storage, my files and blobs here, I’m also going to say you can only access the storage account or bucket from these other cloud resources, VNets or whatever that I have stood up here in my cloud.” Now, what if you are multi-cloud? That makes it a little bit more complicated, right? Josh, like if I’m using storage over in Amazon and I’ve got an application running in Azure that needs to access it, you don’t have that … They don’t bake in that kind of access for you because of course they’re interested in keeping you all in one cloud, but there’s still ways that we could lock that down and that we could route those requests over a trusted path.

Josh Williams:
Absolutely. Well, and it’s kind of going back to the same theme it seems that I’m really beating on here, and it’s what you don’t know, you can’t secure. So when it comes to multiple accounts or multiple an Azure AWS environment, two different environments. You said earlier, I was just on with a customer and what we were talking about, the main thing is I have AWS, I have Azure, two different teams running these things. I as a security engineer, I just don’t know. Like I’m having to log into all of these different accounts. I’m having to log into Azure stuff and I don’t have the time to log into all of them and run compliance checks across all of them. I need something to see all of these accounts. So I know as I’m using them, which ones I’m able to … I need to see all of it and know that I can secure, what to secure in all of these different environments.

Randy Franklin Smith:
Yep. Mike says, “So key here is where was the security architect? This needs to be in design, not after deployment.” It’s so true Mike. I don’t know how long you’ve been in IT and security, but if I revealed to you how many decades, you’d know kind of how old I was. And the very first year that I started in cybersecurity, it was called information security back then, we were saying that and we’re still saying that decades later. So I guess some things don’t change. Harry says, “A common language across CSPs would help as well.” Mike says, “I’ll match you. I predict firewalls.” Yeah. Right. At one time firewalls were cyber security and cybersecurity was firewall. Flavio, it’s still called information security. Yes, it is. Cybersecurity is kind of a subset of it. I agree, but let’s not split hairs or play semantics games.

Randy Franklin Smith:
So the thing here folks is we need to understand the benefit of service end points and private link in the cloud. The other thing is that, and it just occurred to me literally while you were talking, Josh, is it’s a lot more work to do this right and to have defense in depth with layers of network controls in front of your cloud resources, but it’s been proven that it’s necessary. And so that means, wow, we’ve got now a lot of firewalls to manage. And again, when we use the term firewall in these webinars, we’re talking about anything that is an enforcement point of network traffic, Josh. And that’s the thing that I think folks will be interested in seeing with your technology is if it’s a network enforcement point, you can bring it in to your database and put it all on one pane of glass and enforce consistent policies and visibility.

Josh Williams:
Right. And help with the decision. So to kind of go back to what was just mentioned about the security architect, to help the security architect, security engineers, network engineers, even cloud engineers, and to help them make intelligent decisions, give them the information they need so they can make the best decision possible about deploying any kind of risk mitigation factors.

Randy Franklin Smith:
Yeah. Let’s see here. Okay. Here’s another thing that we’re seeing over and over again in the past few months and that is folks are using containers which are awesome. They are a more efficient way of getting the benefits that you do from virtual machines, like way faster, way more efficient. And often times when you talk about security and containers, what you hear and rightly so, but you hear kind of a limited focus on the lack of security boundary between containers on the same host. And we know about that, that is very real, it’s very true and it’s something to understand. But we’re seeing something more fundamental and elementary leading to hacks of container based infrastructures or container based environments and applications. And that is simply unprotected Kubernetes consoles and other elements of your orchestration infrastructure.

Randy Franklin Smith:
So you can roll out containers and you can have done a good job with your container security policy. You can have paid good attention to the provenance of your images for containers. And if any of have looked at containers Docker security, you understand why the provenance of the images that you base your images on is important. But if you just stand up a Kubernetes infrastructure and start running secure container designed applications in it and you fail to secure the container orchestration, the Kubernetes layer or if you make the Kubernetes layer accessible again from a network point of view, then it doesn’t matter how secure the containerized application is because the infrastructure, the foundation it’s running on is insecure. And so just do a Google search on unprotected Kubernetes consoles and you’ll see what I’m talking about there.

Randy Franklin Smith:
But again Josh, to me it goes back to what we learned with running virtualization. So take VMware. We said, “Man, we need a whole separate network, a management network for vCenter and the ESXi servers to run on and the database for vCenter and its authentication and all of that, that needs to be a whole separate, protected isolated network.” Then we have a network for the VMs to talk to their clients, the VM servers to talk to the clients and then a whole separate network for like your storage fabric and stuff like that. But it’s the same thing here Josh, is yeah you need communication between your Kubernetes cluster and the console and all of that, but that shouldn’t be on the same network as your containerized applications. Josh.

Josh Williams:
No, absolutely. I mean, kind of thinking about it, put it in firewall terms almost because this is highly relatable. You don’t want to put what manages your firewalls. You don’t want to put it in a network where it’s going to be easily accessible without any controls on it, where the only thing you’re depending on is login credentials whether they’re through a TACACS radius or God forbid, local, right? So we want to make sure as we’re building out orchestration infrastructure, things that like a Kubernetes or anything that’s able to control a whole lot of very important systems, if those aren’t controlled at least with defense in depth like you mentioned earlier, we want to make sure let’s start with the first point of put them in their own VLAN and make sure that VLAN is locked down or put them in their own type of domain where they can be locked down and the traffic that’s not supposed to get to them, they’re not able to get to them. Let’s just do that first and foremost. Right?

Randy Franklin Smith:
And that way across the board, whether it’s a microservice or Mongo or Kubernetes, if there’s a zero day exploit discovered or if there’s a misconfiguration on those systems, it’s not just open to everybody. You have to have gained access to that LAN segment or whatever you want to call it in order to exploit it. Yeah. Okay. Well, here’s the thing, it’s not as though these cloud servers providers have not baked in the capability to lock the stuff down. So as soon as you stand up a virtual machine, you’ve got a VNet and that VNet has a network security group associated with it. And you can create additional network security groups for every virtual machine or NIC that you put on that virtual machine. And this is not an extra cost. This is not an extra product. There are cloud firewalls, there’s Azure firewall and AWS has theirs and there’s a web application firewall and all the … And you can buy checkpoint or any other firewall vendor through, as a virtual appliance or as infrastructure as a service, but you don’t even have to do that.

Randy Franklin Smith:
You’ve got network security groups in Azure. I don’t remember what they’re called in AWS at the moment, and for all practical purposes and intents, it’s a firewall. And you can deploy that at the VNet level or each individual NIC and this doesn’t even require you to configure it. The nice thing is it’s all at the cloud level so that NIC and that VM could be Linux or it could be Windows, but it’s not like you have to go in and configure Windows firewall or Linux IP change or whatever else. It’s all configured at the cloud level. It can be made part of resource groups and templates and scripted and automated and all of that stuff. But there’s a lot of them and you know how with firewalls the biggest security issue are misconfigurations because you get lots of rules and it’s hard to correlate those rules to keep them up to date, to keep them consistent. It’s all about automation. Well, all the same issues apply with network security groups.

Randy Franklin Smith:
And this is just a slide from another webinar that I did on cloud network security. But so network security groups, just visually showing you how you can apply them at the VNet level or at individual NICs on each one of your VMs. And you can reuse a network security group as well. So it’s a matter of using them, but also using them in an effective way. And again, I think you’re really going to like what you see from FireMon. Okay. Here’s my last one. And that is lack of understanding of complex cloud resource interaction.

Randy Franklin Smith:
So this slide is about when you’re building a cloud native application or implementing a system in the cloud and you’re using multiple cloud native resources. So in the situation that I’ve named here, the Capital One AWS hack by Paige Thompson, otherwise known as erratic, the situation involved a web application firewall, the AWS metadata service, an S3 storage bucket, something called roles in AWS. Oh, and of course, AWS instances otherwise known as virtual machines.

Randy Franklin Smith:
So they had an application that was vulnerable to server-side request forgery. And so that’s where your application can be tricked into making up a URL based on information that you the bad guy have supplied in the guise of a user and then that web application will go and request that. But it’s requesting it not as you, but as itself. So they had a web application firewall that allowed this through, through a misconfiguration. And then the application was tricked into asking the AWS metadata service for credentials to a particular AWS role. Now you kind of have to get into AWS programming on the AWS environment to maybe fully get this. But the bottom line is the AWS metadata service is I think that’s a horrible name for how important it is.

Randy Franklin Smith:
It’s basically how you as a program running on an instance, talk to the AWS cloud and get things like tokens, identify yourself and get things like tokens for accessing other resources in the cloud. And the way AWS was designed back then, I think they’ve made some mitigation since then, the way it was back then is anything running on a given instance, so any program, any script or an application that gets tricked into making a request against the AWS metadata service is regarded by AWS as being part of the trusted computing base on that instance on that virtual machine. So here’s what … Basically what this allowed is somebody out on the internet to send a request through this web application, it made it through the web application firewall and they had supplied the static IP address of the AWS metadata service. And the request was for a token that would vouch for it to being a member of a certain role. And this role is a way that you can grant access to resources in AWS, such as S3 storage buckets.

Randy Franklin Smith:
So what they got back was that token, the bad guy, and then they were able to turn around and use that token to go directly to that S3 bucket and download gigabytes and gigabytes of customer data. So there’s multiple breakdowns here. First of all, the web application was building URLs based upon user input and that is server side request forgery. Web application firewall didn’t block it. AWS, Amazon bear some responsibility with how the metadata service and assumptions that it made back then. And then the S3 storage, here is where one of the security reports from an analyst that I read said … and what’s worse is the S3 data wasn’t encrypted. All right, definitely that would have helped, but no one mentioned, oh, and that S3 bucket was exposed to the internet where all of the research that I get indicates that that S3 bucket was only needed to be accessed by Capital One applications, not every Tom, Dick and Harry on the internet that happened to get a token to that S3 storage.

Randy Franklin Smith:
That’s like putting S3 storage or Azure storage, cloud storage out there on the internet is like just taking your firewall. I was sorry. It’s just like taking your NAS and connecting it directly to the internet and saying, “Okay, we’ve got to make sure we protect access to all of our user accounts on that NAS.” But anyway, there you go. So the bottom line here is not any one of these specific things. It’s the whole interaction. It took, the attacker was a former AWS developer who had intimate knowledge of how all of these things worked together. And so it’s understandable that your average web developer would not have thought about how this combination of technologies would expose Capital One in the way that it did, but it does. And so again, like people have been saying, we’ve got to get security into the design. But the other more tactical and immediately easy thing is we need to get more network security controls, more layers of network security in front of these resources.

Randy Franklin Smith:
And then aside from all of these technical things, when we move stuff to the cloud, it’s easy to forget the compliance regulations still apply. And with the proliferation of cloud resources and the fact that teams are directly standing the stuff up, existing controls and procedures that ensured you had compliance can be inadvertently bypassed not by any willful or malicious intent, but it’s just, it’s outside our normal established, mature procedures.

Randy Franklin Smith:
And you know what, I think that’s one of the ugly truths of cloud is part of its agility and reason that it’s so fast for getting things going is not just the technology and the model, but the fact it’s an artificial compliance debt that we’re building up, Josh is we haven’t caught up. Corporations and governance haven’t caught up with building controls and compliance and change approvals and security architecture into the system design lifecycle or whatever you want to call it for cloud. And therefore it’s faster, but you’re building up compliance debt as you go along.

Josh Williams:
I love that phrase by the way, compliance debt. That is a great one.

Randy Franklin Smith:
Well, it’s going to something they call, I think it’s called technical debt with software development. You can ignore best practices and write messy code and get it done faster, but you’re building up technical debt.

Josh Williams:
Right. And the chickens come home to roost and the auditors show up. And here’s the thing, as you migrate into the cloud, they’re not going to give you the pass on it, right? Nobody’s going to say like, “Well, you can be less secure out there. That’s fine.” That’s not going to happen. So as you migrate to the cloud, as you go into these … this IT sprawl happens, and as you go into your different cloud providers or your one cloud provider, whatever the case is, at the end of the day, you still have to ensure that you’re holding up to the regulatory compliance standards that you are with your on-prem environment. So like I said, the chickens will come home to roost, right? The auditors are going to show up and they’re going to say, “Okay, how are you ensuring and maintaining AU-003 for NIST 800-53?” It’s going to happen, right? So we still have to ensure you don’t build up all that compliance debt and have to pay the piper, and I’m killing with analogies right now, but you know what I mean? Like you’re going to have to end up doing it.

Randy Franklin Smith:
Absolutely. So bottom line here is cloud native microservice-based applications often rely on simple API keys and machine identities. Sometimes those identities are inferred. Think of the Capital One AWS pack or there’s also on business wire a really great report about unprotected machine identities. So at the same time, these same resources are internet facing resources. They’re addressable from the internet, meaning that the only thing standing between anyone in the world and that data is the API key and the machine identity, which are not strong in the first place.

Randy Franklin Smith:
Second of all, all of the stuff is complex. And I tried to show that with this slide, with the Capital One AWS thing, but here’s a good quote. Given the complexity of cloud services and the ease at which misconfigurations can occur because systems need to become usable and functional as soon as possible, it’s important to approach cloud infrastructure with a defense in depth approach.

Randy Franklin Smith:
And one of the big layers of defense that is missing here and that is most easily deployed is network defense. And if you want a list of examples of the things that I’m talking about, real-world examples of all these vulnerabilities, check out those two links there from API security and security discovery. But the bottom line is where’s defense in depth? Cloud platforms provide a layer of network defense, but it is user optional. So we’ve got to deploy it. I’m going to turn things over to you, and then we’ve got a couple of polls along with Q&A. So Josh, why don’t you show us what you can do that is relevant to all these issues that we’re bringing up and I’ll make you the presenter, bam, there you go.

Josh Williams:
No, and you’re absolutely right. And I really appreciate all the information and especially the points, because all the points I believe are from my interactions with many accounts in many different just teams and organizations, it’s come up to a lot of what we’re talking about here, it seems to be the recurring concerns. Because as you move into the cloud and as … moving to the cloud at the speed that, I want to be nice about it, but I really want to say at the speed that people that just don’t totally understand all the underlying processes or the security processes for sure, at the speed that they want you to implement, there’s a lot of trepidation that comes along with it because, well, one, as a security engineer, I want to keep my job.

Josh Williams:
As like a network engineer, I want to keep my job and I don’t want to get out there due to some business forcing me, some business function forcing me out really quick into an unsecure environment. So yeah, let’s just, let’s talk a bit about FireMon and let’s talk about what we are doing to help with these nine points and plus a few extras. So we’re looking at three main pillars that we’re building off of here at FireMon and that is around automation, risk mitigation and compliance. And the idea around automation I think is extremely simple, but to me, automation is a natural progression for what we do. So when we’re looking at being able to ingest so much information about your firewalls, whether they’re in Azure, AWS, your on-prem firewalls, your routers and switches, the ACL’s there.

Josh Williams:
As we pull that information in, we’re going to help you go into clean up and make any adjustments to it to make it more secure. Automation to me is a natural progression from that. Because once you have a secure environment, once you, and like I said, I’m beating analogies up today because once you’ve cleaned your room, well, you want to say, “Okay, how do I keep my room clean?” To us, automation is the way of keeping your room clean. It’s the way of saying, “Okay, I now have a way to ensure that this new clean environment that we either spent project management cycles on, and we did a huge project on to clean up these firewalls, how do we keep them clean now?

Josh Williams:
Automation is a very natural progression with risk mitigation that comes in so many forms because with risk mitigation, we want to be able to look at what might be exposed on the firewall, what might be overly permissive. All these different layers to say, how do we mitigate risk in your environment, especially to say in your Azure environment, in your cloud environment, where we are looking at the behavior of. If you remember, Randy put up that slide that showed how you can have multiple NSGs across your VNet and up on your sub-net.

Josh Williams:
So how do you understand that behavior? How do you know what on NSGs need to be modified in order for access to one, happen because the business still needs to run, and two, not too much access because well, the business doesn’t need to get hacked. Compliance is like what we talked about in that last point where compliance isn’t going to give you a buy just because you’ve moved to the cloud. Just because you’ve enhanced and grown your IT infrastructure, you still have to ensure that you have compliance as you go from that on-prem environment into that cloud environment. So before I really got to dive into some of these main points, I think Greg said something earlier in the questions, he made a great comment and it was about something to the extent of we all have … people just believe you go into the cloud and it’s all secure.

Josh Williams:
Well, I like to evangelize this because FireMon we did the 2020 hybrid cloud security survey. So we got a lot of feedback on it. And one of the main points, probably the main shocking point that I got from the feedback is the lack of knowledge on the shared security responsibility model. And this is a model that the cloud security providers put out that say, “Hey, this is where we are draw the line of demarcation. This is where we say we are no longer responsible and this is where you as our user is responsible.” And as you can see, I think AWS does a great job, the responsibility for security in the cloud, that’s on you, that’s on the customer. Responsibility for security of the cloud, that’s on AWS. So they’re going to make sure nobody can just get into their data centers and get to their servers and for any kind of hardware type vulnerability.

Josh Williams:
So I assume we’re talking about, if you all remember meltdown, specter, those kinds of vulnerability issues. That’s going to all fall on the hardware. What you need to worry about is your network security policies, your assets, what image are they running? Are they running a secure image that you produced for your organization to run or are they just running the normal Ubuntu image that really isn’t as secure as you need or your organization demands? So I think this is really important to at least evangelize to ensure that your users, the people that are working in your cloud environments understand this, know this and especially for management. Because like Greg’s saying, you don’t want people just to be like, “Oh, it’s in the cloud. It’s secure, right? Because the cloud guy secured it. The Azure, they secure it, right? Microsoft’s good.” No.

Josh Williams:
So I think this is great to evangelize and I’m really glad that point was made. So as we go into this cloud migration, as we see this movement into the cloud, you might already be there, you might not. If we were to take the conch shell, because I feel like sometimes IT is very much Lord of the flies, right? But if we were to pass the conch shell around everyone in the audience and we were to say, “Okay, tell us about your cloud strategy, either the one you’re developing now or the one that you’ve executed.” They would all be very individualized. However, I believe that we could wrap them up into kind of these three main buckets. A lifted shift, the going completely cloud native and rearchitecting everything. All of these demand different positions to look at different perspectives because they’re going to just demand different strategies from a security perspective.

Josh Williams:
Now, a lot of this stuff gets talked about very high level and a lot of these things can be … good decisions can be made about how we’re going to perform these securities. But again, going back to a comment I think Mike made about where is the security architect, that is where what we believe is the operational day-to-day headaches. So what do we do to help with these day-to-day headaches? And here’s just a list of some and I think these are all very important is one is compliance. We talked about that. How do we and what do we do about compliance because we know it’s not going to go away once we go into the cloud? We have to carry that with us. We don’t want to incur more compliance debt. I love that.

Josh Williams:
Visibility into the infrastructure security. Again, this is another thing we’ve talked about, right? This is a day-to-day thing. The security architects need to be communicating and understanding and gaining the knowledge of so they know how they’re going to have visibility as they migrate into it. Then we get the lack of qualified staff. I’m going to step over that one for right now, because we’re going to come back to that, we’re going to circle back around to that one. Then we have setting consistent security policies. And if I could sum up FireMon really in one bullet, this is really close to it. This is really close to the bullet because I have this very deep philosophical thought about network security policy management and it’s around that bullet right there.

Josh Williams:
How to set consistent security policies because setting a consistent security policy is much more than just saying, “Okay, we have the same policies here and here and here.” It’s saying we have the right policy in the right spot at the right time. So it’s combining so many more elements to ensure that the policies are correct. And I would say we at FireMon, we strive for that thing. That takes us from taking in your current policies, helping you right-size them all and then automating all of these policies to ensure they maintain their consistency, they maintain their correct implementation. And then the last one we have here is I believe is the classic struggle, right? If we were really looking at something that is, I think Randy and I were talking about earlier, it’s not new, it’s this classic struggle of the pace of changes in security.

Josh Williams:
And I’ve heard it said, DevOps was created because infrastructure was too slow. And I think that was said in jest, but I believe that there was a bit of truth to it because I think it was a DevOps engineer that was saying it. But the idea is around how can security stay and maintain itself, especially when we get to the cloud? And it’s been mentioned in the comments, we’ve talked about it, there’s a pace once you get into the cloud, the pace is it’s a great, it’s a high frequency pace. For better or for worse, it is what it is.

Josh Williams:
So how do we as security engineers or network engineers or even cloud engineers, whoever’s concerned with it and I believe it’s all part of our responsibility, but how do we ensure the security stays up with it? So this is just reiterating a lot of what Randy’s talking about, these things that should be thought about as you go into the design mode of your cloud deployment. And if it’s past design and we’re already in deployment, well, now’s the time to start really thinking hard, how do we implement these? How do we start to think about all of this?

Josh Williams:
So I want to step back to that third point, and I really want to talk about what we see as the biggest security threat. And we know we could scratch out cloud here because we believe this is the biggest security threat to your environment. And just kind of a quick story, Bill Gates with I think it was Dean Kamen did the water purification systems. And from what I’ve read, what brought Bill Gates to that is the idea that he was looking to do some philanthropic work and he was looking to do philanthropy, let me get my words right. And so as he’s doing this, he’s saying, “What can I really attack? What human problem can I attack to make my money go the farthest to do the best good for all people?”

Josh Williams:
And he said, “All right, you know what? I think if I can provide clean water, that’s a great start. That’s the biggest bang for my buck.” Well, we’ve done the same thing. Through the survey I was mentioning earlier, through countless amounts of customer interaction, we have come down to misconfigurations. That is to us one of the main concerns of all security organizations. And there’s a lot of great automation material out there right now, but automation is only as good as the information you can provide to it.

Josh Williams:
So there’s this whole ecosystem that needs to be built to allow for the right information, for the right decision-making, for the right automation, to where you can take human hands off of actual deployments to ensure that fat fingers don’t happen. Or like I was saying earlier, I can’t tell you the amount of times as a network engineer I’ve put the wrong route in a routing table and advertised something incorrectly. Or as a security engineer, I put in a really large IP space, a subnet on a policy and we just allowed access to it. And luckily enough, maybe I went back in and found it or a friend of mine found it and was like, “Hey dude, I got you covered,” which good on them. But at the end of the day, I’ve made by far my fair share of mistakes. So the idea is misconfigurations, and this was the loud in our survey that a high amount of businesses fear of their misconfigurations or misconfigurations on their firewalls or their devices for their security posture.

Josh Williams:
So let’s talk a little bit more about that and let’s talk a little bit more about what’s causing them. Because once we, I think we can dive into the root of the cause, once we can get that, we can really start to form the solution. And what we’re seeing here is if you look at this complexity curve here, you see the yellow curve is growing exponentially and that’s based in, well let’s say partly due to the cloud and that’s a major point that Randy made. I think his last point where he talked about the hack on AWS is that there’s so much complexity in the interrelationships of all these different cloud providers that it’s the natural maturity of all of these technologies that were a growing complexity with the interrelationships of everything. With that growing complexity, you would imagine that our resources are growing at the same rate. And what we find is it’s not happening it at all.

Josh Williams:
As you see the exponential curve for the complexity, you see a low rate linear bar for resources, meaning that our resources are not even growing close to what they need to in order that personnel are able to take care of this complexity that’s growing. And we’re finding that with the amount of complexity, the growth of complexity, you’re incurring unmanaged risk. And with unmanaged risks, I mean, you see how the domino falls, right? With unmanaged risk, you’re increasing the probability of a breach, of an attack, of a successful attack. So what do we do? I think the idea here is how do we attack this complexity gap? How do we say, “Okay, we got the resources growing at a linear rate. We got an exponential growth on complexity. How do we cross the spread, close the gap or at least begin in some way closing the gap?”

Josh Williams:
And just to kind of go back to what I was saying at the beginning, one of our main pillars here is automation. And so at FireMon on what we’re looking to do is like I was saying, the natural next step for us. Because at FireMon and I hope when you think of us, what you’re thinking about is like, oh yeah, it’s that wonderful company with all these cool people. And what they’re doing is they’re taking in all this firewall information, they’re giving us really good information. They’re helping us clean up our firewall, all of our firewall rules and policies. They’re making sure that our configs are, everything’s right, that we’re in compliance. So this is what FireMon’s doing, but we want to take that a step further and we want to make sure that as you continue to stay in compliance, because once you’re in compliance, you want to stay there.

Josh Williams:
You want all your rules to stay within the compliance standard that you’re held up to. Secondly, you want to make sure that when that auditor shows up, like what we were talking about earlier, Randy and I, when that auditor shows up and says, “Hey, it’s time for your audit,” that you have the artifacts to provide and that comes also with automation. You want a way while you’re automating and making changes to your environment, you want a way to be able to say like, “Yes, we know here’s our process for all of our changes. Here is how we do it and here is the documentation of all the rules.” So here’s how we can spot check. Here’s how we can know these, that we’re within our STIG or PCI or whatever standards you have to hold up to.

Josh Williams:
And it all begins for us, or well, it doesn’t all begin, but it’s just taking on a new set of legs with automation. And so with the automation, we’re able to build out whatever your workflow is. We want to build into it and we want to partner with that workflow. We don’t want to come in and blow everything out of the water because that’s not helpful to anybody. We don’t want to change anything that’s not broken. And trust me, I’ve been on the other side of that table, many of times where you work for years trying to get the workflow to be absolutely correct, and you know what, it works. It’s not perfect, but it works. Well, our goal is to come into your request, your firewall requests and say, “How can we integrate with what you have and how can we enhance what you have now? And then how can we get it into the devices?”

Josh Williams:
And then we close the loop by saying, “Now that it’s in the device, we’re going to ensure that everything stays within compliance.” Even when you’re making manual changes outside of using FireMon to automate the change, how are we able to go back through and say, “Okay, all your manual changes on these NSGs and Azure or your security groups in AWS, all of these changes totally fine. They’re still within standard.” So we want to close that circle and we want to partner and pair with your current process that’s not broken. Now, if you come to us and you say, “Hey, we have a broken process,” no big deal. We do this every day. We have cookie cutter processes to help get people involved, to help get requests involved, to help design.

Josh Williams:
So we are able to provide to you a buffet of here’s how we can work with you and work with what you have. And it all starts with us just gathering the right information for you, helping you clean it all up, helping you get within compliance and then with automation, helping you stay in compliance. And just again to kind of talk on the integration ecosystem, as you can see here with all the logos we have up here, I mean, this doesn’t even cover them all, but we’re able to integrate with a lot of what you can bring to us. And I think that’s what fourth or fifth bullet down where we talk about APIs, that is very strong. So that means here’s a couple of things. That means one, we’re going to support, and it’s easy to support integrations with all of those products that you see up there especially around SOAR.

Josh Williams:
SOAR seems to be the subject that everyone’s talking about. And we’re really wanting to integrate, and we’re working. There’s a SOAR vendor I’ve been working with a lot lately and men, they’re doing great things and we’re really integrating good with them. And it’s just the more we get involved, the more power we can see us provide to the SOAR, for instance, the information we can provide back to the SOAR to make, so the response of that threat hunting, we can respond appropriately to it, help orchestrate it better. Plus we can be a part of the actual response. So there’s so many ways we can plug into that. But the second point I really want to make is let’s say you home grown your own tools. Well, that’s fine.

Josh Williams:
We have the APIs and we are absolutely okay with you hitting our APIs, grabbing our information about your system, because we can take that. We have information about your system that’s already, all the compute work’s done with it. It’s already done. So let’s hand it off to you in a very nice, good fashion for your homegrown systems. So with our APIs really what it’s, I mean, it’s up to your creativity or your organization’s creativity. I mean, a step further, it’s up to your creativity and our creativity. So we want to work with you on this to be a part of how do we make your system better? And really for us, it starts with the APIs. And so here are some of the drivers that we continually see, the reduction of human error.

Josh Williams:
I mean, obviously that’s what we’ve talked about with misconfigurations, the reduced operational security costs. To me, that seems very obvious, right? We don’t want to spend so much money on it. Achieve security agility. That goes back to that point that we were talking about with the old classic head budding of, we want something quick, but security needs to keep up with us. And as security, we kind of have to take a step back because we know we’re going to allow business functionality, right? If we weren’t, if we had our way, every computer would be unplugged from the internet. Everything would be unplugged from the network and everybody would be on an island. But that’s not the case. Right? So we’re giving into the business functionality, which is absolutely fine because well, the business needs to function.

Josh Williams:
So we have to have some security agility, and that’s the way we’re taking … that we’re not having to move the dot in the triangle to say, “Well, if you have security, you’re losing speed.” And we don’t view it that way anymore. We’re viewing it as we can provide you both of these, we can let you have your cake and eat it too and that is through our system. This becomes extremely, extremely loud and clear when we get to the cloud. And as you start to migrate into that fast paced environment, we want to make sure that we’re able to automate to it, we’re able to keep it cleaned up. And that way, as the business grows in the cloud which is easier to do, there’s less friction points there, you can keep your security on pace with that business growth. And then we want to maintain continuous compliance.

Josh Williams:
It’s something again, I feel like I’ve belabored that point a lot that as you roll into the cloud, your compliance goes with you. You don’t get to say, “Yeah, PCI is just for on-prem or NIST, that’s all for on-prem only.” So sorry, you don’t get to say that. And just to hit one more time on misconfigurations, the idea is that misconfigurations are going to cost you money, right? And that’s what a lot of this comes down to this talk about bottom line. And that is if you neglect due to compliance, you’re not living up to your compliance standards, you don’t have your environment in that compliance standard and you neglect it, a misconfiguration happens, you lose money. Now, not just losing information and the bad PR that comes with that, and the head rolling that comes with that, but there’s also the money aspect.

Josh Williams:
And I feel like that’s … Sometimes the security engineers and I’ve done it too. I’m like, “It’s just money.” But yeah, I mean, it is just money and it’s a big deal. And so you’re able to, as a security engineer, especially when it comes to cloud, you’re able to say, “As we secure and as we grow in the cloud and secure in the cloud, we’re able to at least have some sort of cost savings from securing our environment and staying within compliance because the risk is too high to not, especially with a monetary value attached to it.” So let’s just talk through some use cases around how we automate and especially automate to the cloud. And once we do that, I want to show you all a couple of screenshots of what we have today and how we are pulling the information and kind of talk a little bit more about it.

Josh Williams:
I believe we’ve really get some of the use cases, some of the drivers down based on just vulnerabilities that we’ve exposed and talked about. Really the need of visibility, and I’ll say this, I say it as a joke now, I didn’t really say it as a joke about five or six years ago. But whenever I was first getting into actually deploying into a cloud, when I was working at another company and I was on the other side of the table, we were going through all the cloud, the technology is in the cloud and just everything that we could do and from a security perspective, what we could see, and I was like, “Man,” I said, “You know, we’re getting thrown back in the 90s. This is crazy. I can’t believe that we’re losing this much insight in the cloud environment.”

Josh Williams:
I wouldn’t say it’s as bad as it was five or six years ago, but we still aren’t able to get the visibility into the cloud like we are into our on-prem, but we’re able to get a lot right now. And so we see that people are wanting to gain more visibility and I have those discussions almost every day where people want to gain more visibility. They have multiple cloud accounts and they’re saying, “Okay, I need to get that visibility.” They want to track changes in the cloud because DevOps has all of their systems going and who knows what’s getting spun up. We want to track changes. We want to make sure that all the changes are aligned with our compliance standard. We want an audit trail of that because when the auditors show up, you need to have those artifacts to provide.

Josh Williams:
We need faster SLA, and this is again, just things I’m just beating this dead horse to death, and that is we have to be able to move at the speed of business. So we want to be able to ingest information, make good decisions, clean up our environment and then automate to the environment. So without further ado, I’m going to show you really quick just a couple of screenshots that we have from our new 90 release. And it has our, I’ve grabbed a Microsoft Azure instance for this or a subscription. So what we’ve done is as we pulled in the whole subscription, and if you know FireMon, you know that we provide key performance indicators and we’re showing you just some valuable information about your environment off the bat. And what we’re seeing here is for instance down at the bottom, you see device, the security complexity index.

Josh Williams:
And how complex is the environment underneath? There are the security concern index. And how many failures do you have on controls? What’s going on down there that … Is there anything that I need to really be concerned about to go in and fix in my Azure subscription? We can look at changes and this came from our lab. So you don’t see any changes right now, but we can see changes in our configuration. So if you come in one morning and you look and you’re like, “There were 700 changes last night.” Well, with those changes, you might have something that you don’t want as a security engineer that you might have something you don’t want in there. When somebody puts in … when there’s over 700 changes in a night. So that says okay, there’s a high amount of changes last night, I need to go in and make sure that nothing crazy is now open to the internet and I need to start reviewing.

Josh Williams:
So we give you that change over seven days or a number of days. Also, we have the device complexity. So this is based on your amount of rules and sources and destinations and your number of rules. So there’s a lot of information we take from your Azure environment and we put into this complexity score to say, “Hey, you know what, you’re doing pretty good. Yeah, you’ve got a lot of rules, but at the end of the day, nothing’s too complex and you’re not opening things up you probably shouldn’t be because your sources, they’re all consolidated. Everything looks good.” And then we have compliance failures, just rules that you might fail, controls that you might fail in whatever compliance standard that you’re using, whether that’s NIST or PCI or whatever the case is.

Josh Williams:
Then with security manager, what I’m showing you here is our inside of security manager. I’m showing you our assets page. And so this is where we’re going to show you, and this is going back to what Randy and I were talking about earlier, where Randy was saying you need to have an inventory. Well, this is our inventory. This is our inventory of all assets that we have in the environment. And so I have actually, and just in this environment, I just have two, but I’m showing you all the assets I have, but more importantly, I’m showing you the context around the assets, because that’s really I think as a security engineer or from a security perspective, what you’re looking for. What’s the name of the device? What operating system is it running? Because maybe we don’t want them running the Ubuntu server operating system because that’s not hard into our standards. They should be using an image that we’ve produced for Azure to use.

Josh Williams:
Maybe we don’t want them using a specific size because we know that that’s going to produce so much more money and we need to have some kind of report on that. This is all searchable. So if you wanted to search for show me, or you set up an alert to say show me anybody that’s using Ubuntu server. Then we’re able to do that because we’re able to glean that information and then create it in an index file or an index server or database where it’s searchable. We’re going to show you the resource group inside the sub-net, the VNet, but importantly, we’re going to show you if it’s got a public IP. I think that’s important to know, right? You have the private IP that is going to connect you in the internal Azure environment, but is it exposed to the internet? Is it …

Josh Williams:
Look, I can look there and tell you that’s not RFC 1918. So I’m telling you right now that that’s probably exposed to the internet. So okay, is that okay? Is that type of server okay to be exposed to internet? If not, then we need to remediate and then we get the NSGs. What is it protected by? If we had multiple NSGs, we would show you the multiple NSGs. We’d show you NSGs 1, NSGs 2 because it’s attached to the VNet, it’s attached to the sub-net. So we’re trying to give you that inventory, but not just the inventory. We’re trying to give you the correct amount of information and context around that inventory. Next is what, again, our bread and butter, what FireMon has been about since the inception and that’s just what’s changing in the environment. So we still want to provide for you in the cloud any changes that were made and this goes back to that KPI that we were showing earlier on the overview dashboard.

Josh Williams:
But what we want to show you is, was there changes made? More importantly, and some people might not like if you’re making mistakes, but we’re going to show you the user that made the change. So if someone’s coming into a specific Azure subscription making 2,464 changes, well, we want to know who did it, right? Because if you’re coming in and make it 2,464 changes, then yeah, we need to have a talk probably, right? Unless this was planned and cab approved. So we want to still provide all that information for you. Mainly what I’m trying to show you with this is all of the benefits and the features and the value that FireMon has provided for so long, we’re still bringing into the cloud. We’re not trying to make anything different. You’re seeing everything the same.

Josh Williams:
So you can see your on-prem. You can see Azure, you can see AWS, you can see Google cloud, whatever it is. We want to make sure that you can see it all together instead of having to say, “Okay, I’m going to log in to 25 different AWS accounts to make sure that all those different changes, that nobody made any crazy changes last night.” And then lastly, what I want to show is our ability to kind of show off our map of how we’re able to map the subscription. Because in the subscription, you’re going to have multiple different networks in the subscription, you’re going to have multiple different VNets in the subscription, but more importantly, we want to be able to show how we can give you the path, because you might not want staging to talk to production or development to talk to production for instance. You might want to run that and make sure that that’s blocked.

Josh Williams:
You might want to run and say, “Okay, if I need to change, make a change in the cloud, what NSG must I change? We can provide that information to you. All you do is provide us a source destination and what service you want to do and we’ll show you what rules or what NAT rules or whatever the case may be, that’s going to change or effect that packet as it flows through the environment. So that’s all I’ve got for showing FireMon and how we can kind of really get in and affect a lot of these issues and roadblocks that might occur as migrating to the cloud that Randy’s brought up, which are all really great, all really spot on. So I hope this has been very informative and I’m happy for questions and visit firemon.com.

Randy Franklin Smith:
Great. And we’ve got some questions for you, and I’ve got a couple of polls for you folks which we will share the results so you can see what your peers face. So first question comes from Dan, Josh, and Dan asks, “What is the architecture of FireMon? Do we have to install agents on firewalls to collect the data and control them?”

Josh Williams:
No, not at all. So what we do is we just need to access your firewall via whatever protocol it wants to provide information on. And I say that to say like, okay, for instance, Cisco ASA will SSH and scrape it or if it’s a Cisco router, if it’s a Palo Alto API. If you’re wanting to go to Azure, yeah, great. We just need that special subscription, a special key for it that we’ll use and then we’ll go in and we’ll hit it via API. We’ll pull all the information for your Azure environment as well. So no, no agents. We’ll go in and do that and then we’ll understand the changes in your environment via sys log. So as your environment changes, we’ll see sys log messages, we’ll say, “Hey, there’s a change. We need to go back out, do a diff on that configuration, understand what’s changed, and if we need to alert you on it.”

Randy Franklin Smith:
Awesome. And so there’s a poll up folks if you want to weigh in on that, I’ll share the results with you here shortly. Let’s see here. Susan would like to know can FireMon look at network activity over some period of time and then compare that to your policies? There’s a lot of things you could show from that. I can see where she’s going with that question.

Josh Williams:
Yeah. So one of the things we want to make sure we can address is permissive policies, let’s say for instance, and I think this is what you’re getting at Susan, is for instance, we want to be able to say, let’s say you have any policy out there, right? The infamous any policy and you say, “Okay, I’m afraid to actually change this because it might affect, negatively affect some business function.” So okay. No big deal. We can look at all the traffic that flows through that policy and then we can say, “Oh, you know what, here’s all the source and destinations. Here’s what’s going on.” So you can now make an intelligent decision to close that policy down and while still allowing the traffic to go from source to destination across the services that you need. And so yeah, we’re able to look at the traffic from a certain period of time to provide you with better information to lessening those permissive, overly permissive policies. I think that’s what you’re asking Susan.

Randy Franklin Smith:
Yeah, I think so. The what if kind of a thing, and also just being able to … I mean, it could highlight the other thing of hey, you are allowing this through and right now there’s no traffic that uses it. Is this something outdated or misconfigured?

Josh Williams:
Yeah. Oh yeah, for sure. Well, I mean, that’s another big thing is saying like, “Okay, what doesn’t have any hints on it?” Do I have a policy where I have, it’s not being used or more importantly, and this is what we love to really show is do I have, like let’s say I have an asset out there that’s a part of an NSG, but that asset has never been the source or the destination of that policy whatsoever. So it’s never been hit in that policy whatsoever. Well, it’s an attack vector if it’s just open and it’s not used, so let’s not open up more things than we have to. Let’s go ahead and close that down. So yeah, absolutely.

Randy Franklin Smith:
All right. And here’s the results of that first one. You know what I find interesting and it might’ve been the way I phrased it, but moving cloud resources to protected virtual networks, that’s the one where I was talking about using service end points or private link, so that every last cloud resource isn’t directly addressable from the internet. That rates lowest and I wonder if that’s because of how I phrased it or just a persistent misunderstanding of what that needs or why it’s so important. Don’t know, but it’s something to think about. And here’s the other poll, launched that. And then Jonathan would like to know, can FireMon detect conflicting or duplicate overlapping rules?

Josh Williams:
Yeah, absolutely. So that’s this call about a security concern, because to me it is a security concern. So let’s kind of provide an example here for a duplicate or an overlapping rule. Let’s say that a project is over and I no longer need access, SSH access to 2.2.2.2. Well, if I have multiple rules or duplicate rules of that in there, I can go and scrub the rule and I can say, “Okay, I’ve denied all SSH access to do 2.2.2.2. Well, I didn’t, even though I thought I did, I didn’t scratch that access out. So what we do is we show you, you have a duplicate rule or you have a shadowed rule, some rule that’s not being hit.

Josh Williams:
So you could potentially in the future create some big, major gaping security incident by not cleaning up appropriately. So that’s what we want to do. We want to show you that we have these redundant rules so that when you go to clean it up, the project’s over, get rid of the access, the server’s decommissioned, well, let’s make sure that we clean it completely up. So absolutely, that’s bread and butter. Yeah. That’s a really big part of us.

Randy Franklin Smith:
Awesome. Let’s see here and let me close that poll and I’ll share the results. And so finally, Fareed asks, “How is licensing? Is that based upon the number of firewalls or users or what?”

Josh Williams:
Yeah. And of course, there’s a little bit of how we can go into it, but yeah, it’s based on firewall. It’s based on devices, based on subscriptions, routers and switches. So we don’t see our routers and switches. They’re not a big major firewall. So we want to make sure that we can provide you the intricacies and the nuance you need as you license your environment out.

Randy Franklin Smith:
Okay, great. Let’s see here. There’s the results on that. Comes out I think how we would expect, partial visibility in terms of what you can see in the cloud. Josh, thanks a lot for showing us what FireMon can do and for making today’s real training for free possible.

Josh Williams:
Absolutely. Randy, I appreciate the time. I appreciate the opportunity. And yeah, I’d love to discuss this more with anybody that wants to kind of take this on and you’ll get a demo. And just go to firemon.com and let’s help secure your stuff.

Randy Franklin Smith:
Awesome. And folks, thanks for spending time with us. Hope it was valuable to you and we’ll be in touch again soon. And bye-bye for now.

Josh Williams:
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