AWS Network Security Deep Dive: Providing Network Protection for AWS Cloud

On-Demand

Video Transcription

Randy Franklin Smith:
Good day everybody. Randy Franklin Smith here and today, we’re going to do a deep dive on the Network Security features in Amazon Web Services. So it’s pretty interesting the similarities and parallels between Azure, which is another subject we recently covered, another cloud that we covered in the same way, and Amazon. It’s just a lot of the same concepts and same features, but the names are a little bit different. But there are obviously some important differences too. I want to thank both Tim and Sanjay from FireMon for making today’s real training for free possible. And hey, you guys have the perfect secret sauce to go along with today’s topic. And I think folks will enjoy seeing how you can manage every single firewall, whether it’s cloud or On-Prem based across the entire globe and get one nice single pane of glass to manage it. Tim Sanjay.

Sanjay:
Yeah. It’s exciting to see so many people taking advantage of cloud nowadays for so many different reasons. A lot of great benefits to be had there but it doesn’t negate the need for good security visibility at the same time. And we’re happy that we’re helping to solve some of those challenges as people adopt cloud very quickly.

Randy Franklin Smith:
Yeah. And here’s some of the stuff that we’re going to get into some of the features of Amazon Web Services Network Security. So we’ll talk about security groups, network access control lists. We’ll talk about what a Virtual Private Cloud is, VPC, and then all these other things that go along with VPCs, we’ll look at Web Application Firewall just a little bit, end points peering between VPCs, VPNs between VPCs and your On-Prem network and lots more goodness.

Randy Franklin Smith:
And when we talk about networking in the cloud, I think the first thing that probably comes to mind are Virtual Machines. And that’s true, but there’s so much other stuff in the cloud too. And that might be cloud-based storage, cloud-based databases, event pipelines, hosted applications. I mean, it seems like every week there’s a new kind of cloud resource or cloud service that’s coming out. Much of it is targeted at developers, but as time goes on we’re going to see a larger and larger variety of these being implemented at our various companies.

Randy Franklin Smith:
Interestingly network security is still a thing with all of these because while the cloud provider, and this is something you guys might want to jump in on here in a second too, Tim and Sanjay. While the cloud provider promises to secure their platform and the man behind the curtain, there’s a lot of security that is still completely left up to the customer and in the hands of the customer. And that’s true, whether we’re talking about high level Virtual Machines or lower level with things like storage accounts and stuff like that. Any thoughts on that from you guys?

Tim:
Yeah. I mean, the providers themselves are responsible for just providing the infrastructure to some extent. The base of the platform to be able to run all the different applications and services. But yeah, at the end of the day, the customer is responsible for protecting the data and making sure that the applications are secured. So in as much as many people think that moving to the cloud environments will make sure that they’ve got a secure, resilient environment, the responsibility is shared between both groups. And often when you’re looking at even regulatory standards or fines, things like that, it’s still the customer at the end of the day, that is responsible for being compliant and also again responsibility on fines that may come up. So right now the model is definitely a mixed model in terms of responsibility.

Randy Franklin Smith:
Yeah. That’s the term, shared responsibility. And let me just throw out a couple of specific examples. If in case people are like, well, what could go wrong? So let’s think of storage accounts. I’m more familiar with the Azure storage accounts. To access the storage in a storage account, all you need is the key. It’s a shared key. And that storage account by default is open to the entire internet. So you get that key, which is just a static key that there’re no controls on how it’s shared, et cetera. Then you’ve got access to whatever is in that storage. So it’s basically a disc drive connected straight to the internet and you’ve got that key and that’s it.

Randy Franklin Smith:
So there’s a perfect example where network security can add another layer of control and mitigation. And that would be if the storage in this particular storage account is only to be accessed by a given set of application servers, then why don’t we limit their network access to that storage account in the cloud to just those application servers. Whether those application servers are local on your On-Prem network and they’re reaching up to the cloud, or maybe they too run the cloud as Virtual Machines. And that’s one of the things that we’ll show you how to do. You can do that with Azure, but you can also do that with Amazon. And in both cases they’re referred to as service endpoints.

Randy Franklin Smith:
Here’s another example. You’ve got a Virtual Machine. If you don’t patch that Virtual Machine or if you leave it open for remote desktop access from anywhere in the world, then everything that Amazon is doing to protect their environments, not going to have anything or any positive impact on your security in that case. So those are just a couple of literal examples of what we’re talking about there. And there’s so much connectivity, there’s connectivity between Virtual Machines, between BMS and other cloud resources between your On-Prem network and stuff that you’ve got on the cloud. You have the need to publish Virtual Machines and certain cloud resources to the internet.

Randy Franklin Smith:
Usually VMs need access to the internet, maybe to pull down patches. And then you’ve got to think about protecting your cloud portal itself as well, the management and administration plane. Okay. So networking and security in the cloud is still a very big deal and compromise of Cloud Virtual Machines can come from all over, not just the internet, but also possibly other VMs in the cloud. So if you mix and match and have different groups, all working inside the same Virtual Private Cloud in Amazon, you’ve got possible risks there, where your higher security VM is exposed to weaknesses in some other groups’ Virtual Machine that happens to be on the same Virtual Private Cloud, VPC.

Randy Franklin Smith:
Or if you have VPN or direct connectivity between the cloud and your On-Prem network, then compromised end points on your On-Prem network could potentially be used to directly attack resources up in the cloud. And then what about business partners? Because one of the things you can do in all of these clouds is enable connectivity between your private cloud and somebody else’s private cloud, and that’s called peering. And it just goes on and on. So just trying to level set and make sure that everybody can really see the risks here, but I don’t want to belabor it because you obviously saw enough risk to sign up for the webinars.

Randy Franklin Smith:
All right, let’s get down to brass tacks and talk about some of the specific objects that you get in AWS. I’d say the two most basic elements to me are Instances and the VPC, Virtual Private Cloud. In AWS, you tend to use the term Instances instead of Virtual Machines. So whenever you see Instance, think VM if you’re coming from more of the Windows world. Virtual Private Cloud, what is that? That is your overall IP network for your cloud account. Now, can you have multiple VPCs under one account? Yes, you can. But basically VPC is a IP address space, and it’s going to comprise Subnets that are all within that IP address space. Does that mean they’re all accessible to each other? No, not necessarily. We’ll get into that as we go along.

Randy Franklin Smith:
But what if you just want to stand up a VM and play with some flavor of Linux really quick in Amazon? That’s really easy to do. You don’t really have to think about the Virtual Private Cloud or what you could call your overall Virtual Network, because Amazon will just create a VPC for you by default, when you first set up your AWS account and it automatically drops your Instance, your Virtual Machine, whatever flavor of Linux or Windows that you’re standing up in there and configures it with an IP address and so on. So you don’t have to really think about if you’re just doing casual VM usage. Nevertheless, it’s there and you want to view the VPC as… To me it’s like the equivalent of your entire Wide Area Network back in the classic locally managed network world. That’s the best way I would describe it.

Randy Franklin Smith:
But you can have multiple of those. So you can set up multiple Virtual Private Clouds, but at the end of the day, it’s an IP address space and there’s logical separation between it. So all of a sudden that’s within your Virtual Private Cloud. You get to control the connectivity between those subnets, but there’s by default no connectivity between that overall VPC and anything else, whether it’s the internet, other VPCs of other customers, other VPCs that your company has, or even your On-Prem network. None of that is there until you actually start turning some of that stuff on with some of the AWS features we’re going to show you. By the way folks, please use the question window for any and all questions, but any other kinds of feedback or thoughts or engagement that you have.

Randy Franklin Smith:
All right. Let’s drill down into the VPC a little bit more. So it’s a virtual network comprising subnets, all of the subnets within that overall IP address space are going to fit into the address space you identify for your VPC. Now you’ve got two kinds of subnets in a VPC, and this could really trip you up. It was confusing to me. And so I want to really call this out. Amazon says you can have Public Subnets and you can have Private Subnets. Now, I don’t know what you think of right away Tim or Sanjay, but when I hear Public subnet, I’m thinking, Oh, this is a range of IP addresses on the public internet. But no, no, no, that’s not the case. When you define your VPC, you’re generally going to use an internal IP address range of something like 10. something and even your Public subnets are going to have that same IP address range of 10 or 192.168.

Randy Franklin Smith:
So then how is it public? It’s public only in the sense that it has a route to the internet gateway. That’s all it means. A completely private subnet is one that just exists within the AWS cloud and has no external connectivity or at least no direct external connectivity. So confusing to me, but that is the thing. And I tell you, except for the documentation, you don’t run into the terminology and the distinction between Public and Private subnets, much beyond where you’re just introduced to them at the very beginning. There is extra flavor of Private subnets in the Amazon Cloud and that is a VPN only subnet. So it has external connectivity, but only to your local network via VPN or direct connect.

Randy Franklin Smith:
Now, how do any of these subnets in your Virtual Private Cloud connect to the internet? They connect via an object called an Internet Gateway. And I think the easiest way to conceptualize what the Internet Gateway is, is just view it as a standard router like what you have on your local network, that’s giving you access to the internet and is managing that NAT boundary. So on one side, on the internal side you have your local address space. And on the other side, you’ve got your internet address space. And that’s what the Internet Gateway is, but it’s just far more scalable and distributed than some little physical network device that you’ve got.

Randy Franklin Smith:
How do you control connectivity between different subnets within your VPC themselves? So allowing one subnet to communicate to another or limiting that, or controlling which subnets are allowed to connect to the internet and which are not, that is with Route Tables. So Route Tables do exactly what they’re called. They’re equivalent to a routing table on a traditional router. Only these are managed in the cloud. It’s again, distributed it’s region agnostic and so on. But that is where you define which subnets can communicate with each other and which subnets can go out through the Internet Gateway.

Randy Franklin Smith:
Anousha asks, if the Internet Gateway within the VPC, would it have a Public IP or the network IP of the VPC? So it has both. It is going to have a Public IP address, it’s dynamic. And just like your router, just a router at a Soho office is going to have typically one little IP address on the internet, right? And then on the other side it’s probably got the 192.168.0.1 address for your local network. That’s what you would expect from this Internet Gateway. Let’s see here.

Randy Franklin Smith:
David Kaplan says, where are the Route Tables? Are they on the Internet Gateway? No, they’re not on the Internet Gateway because part of what Route Tables do is allow one subnet to communicate to another subnet and that’s completely internet unconscious. So I would view Route Tables as the data for your distributed router. So I’ve got some visuals coming up. So before I go deeper into that, David bear with me.

Randy Franklin Smith:
Sandy asks, can you cover elastic IPs? Yes. I’m going too few, bear with me on that too. So let’s just move forward with our slides because some of your questions are anticipating the very stuff I’m going to cover. Okay. So the first thing we do, if we’re just starting off with the cloud, we stand up a VM and now we want to access that VM from the internet. If it’s Linux, we want to secure shell into it, if it’s windows we want to RDP into it. So that’s where we need to get a public IP address, and we need to associate it with that VM.

Randy Franklin Smith:
So this is very similar to how Azure works for what it’s worth, if you’re familiar with Azure. What you’re seeing here is the 10.42.2 address space. That’s a subnet, 10.42.2 would be my subnet. Maybe my overall Virtual Private Cloud address space is 10.42.0.0, it’s 16bit level block. And I’ve got two VMs out there. One is .4 and one is .5. They can communicate with each other, but I want to be able to RDP into .4 from the internet. So I’m going to get a public IP address from Amazon and I’m going to assign it.

Randy Franklin Smith:
A lot of times in the documentation, it says you assign it to a Virtual Machine, but really what you’re doing is you’re assigning it to a Virtual Network Interface Card on that Virtual Machine. Now, if your Instance, I should say, since we’re an Amazon world. If your instance only has one Network Interface, then it’s six of one, half a dozen of another. But it is possible to put multiple Network Interfaces on to a given Instance VM. All right. But in this case, we’ve just got one NIC per VM and so we get a public IP address and we associate it with that first server there whose internal IP address is .4. Now, does that server or does its NIC know its public IP address. Not at all. Let’s just go back to the analogy of a small home office network with a little router out there and maybe you get a block of three or four or maybe it’s five IP addresses from your ISP.

Randy Franklin Smith:
And so you can take one of those IP addresses. Your router has all those IP addresses. You take one of those IP addresses on that router, and you say, okay, I want you to forward traffic that comes into this address to this internal server at 10.42.2.4 and I want you to do reverse network address translation on this reverse NAT. By the way, I only want you to allow port 3389 in on that address. But when you do get an inbound connection request on that port, go ahead translate it to .4 and send it to that same port on .4. So that is what AWS does when you assign a public IP address to one of your VMs. It’s really like it’s going the Internet Gateway and adding that IP address to it and then creating that reverse NAT rule.

Randy Franklin Smith:
Now determines what kind of traffic can come in? That is defined in an object we haven’t referenced yet. And that’s a Security Group. Somebody had asked about Elastic IP addresses. Okay. So this public IP address, 40.124.6.97. That is dynamically when you stand up that VM and turn it on. AWS says, Oh, we’ve got a requirement for a public IP address for this particular VM. Let me go to my range of available Amazon Public IP addresses on the internet. Okay, this one’s available, .97. All right, we are going to assign it to that particular VM. And it, it just happens. What happens if you terminate that Virtual Machine or the allocator? I forget the exact terminology in the AWS world. That IP address goes back into the pot. And the next time you activate that VM, then it will probably get a different IP address.

Randy Franklin Smith:
Now, what happens if you don’t like that? What if you want a static IP address for that Virtual Machine? You can do that, but you’ve got to buy a new object, new service from AWS called an Elastic IP Address. And so now you get a static IP address and you can assign that static IP address to various objects in AWS, one of them being Virtual Machines. But you could also assign it to a load balancer, lots of other stuff as well.

Randy Franklin Smith:
All right. So hopefully that takes care of your question, Sandy. An Elastic IP Address is simply a static public IP address. Okay. Now we get down to our first two security objects in AWS.

Randy Franklin Smith:
Security objects in AWS, for network security that is. So security groups and network access control lists, or I’m going to use the nifty term NACLs for the rest of this webinar if I think about it. So security groups and NACLs, what are they? I want you to view a security group like a policy for a host-based firewall. So if you’re windows think windows firewall, if you’re Linux, think IP change IP, tables or whatever the new firewall for modern distros of Linux is called.

Randy Franklin Smith:
But it is the host-based firewall running in the operating system, that’s how I view it. Now, that being said, let me quickly acknowledge that even though it’s like a host-based firewall, it is not running inside the VM, the virtual machine, the operating system, the guest OS running inside the VM or instance is unaware of the host firewall.

Randy Franklin Smith:
Even if I have admin authority to the windows VM, or if I have root access to the Linux VM, I have no control or ability to change the security group’s policy. Okay, so the reason I say security group is like a host firewall is that it is simply assigned on a host level or maybe host is not a good word to use, it’s assigned on a virtual machine or instance level, meaning that each instance, each VM can have its own network security policy. But I guess the similarity really ends there because it runs in the cloud.

Randy Franklin Smith:
Interestingly, we can assign a given instance VM to multiple security groups. So you say, well, what if the rules conflict? What if my Linux Timbuktu server is a member of security group one, security group two. Security group one allows remote access from the internet and security group two does not. Well, then you wouldn’t be able to get remote access because security groups are such that they only have allow rules, there are no deny rules.

Randy Franklin Smith:
And so you just have to… Whatever the traffic is, whatever the packet or the connection is, it has to comply with all of the security groups. So whatever the most restrictive access is, I guess is the easiest way to put it. Or you only get that access that is in common, the intersection between all of the different security groups.

Randy Franklin Smith:
Security groups control both inbound and outbound traffic for their member instances. And again, just like you don’t really assign IP addresses to a virtual machine, You assign them to a NIC, a network interface on the virtual machine. Well, it’s the same way with security groups. You don’t really put an instance in a security group. You’re really taking one of the NICs on that virtual machine instance and making it a member of the security group.

Randy Franklin Smith:
But most of our VMs only have one NIC, so we can treat them as the same entity. So that’s security groups, network access control lists, or NACLs. These are a classic router firewall configuration, and they are assigned at the sub-net level. So security groups or virtual machine level, instance level network access control lists, sub-net level and you can only assign one NACL per sub-net. And although you can assign the same NACL to multiple subnets.

Randy Franklin Smith:
Let’s drill down into these even a little bit deeper. Are security groups stateful? Yes they are Sandy. You can assign, like I said, multiple… It’s limited actually to five security groups to a NIC. There’s no deny rules, It’s allow only and they’re stateful, meaning you do not need to define mirror rules for response traffic. Let me give you an example, if in a security group we… In fact, I think I can show you an example which would be even better right now.

Randy Franklin Smith:
All right. Yeah, here are my security groups and I’m looking at a security group called database servers. And I added a rule that says RDP. That is TCP port 3389 is permitted when it’s coming from that subnet 10.43. It is unnecessary for me in the outbound rules to go and create a mirror image of that rule that says outbound traffic from port 3389 is permitted. All right, so stateful? Yes. And that keeps it nice and simple. And you notice there’s no allow or deny here. So we’re just opening up and saying, what’s allowed from both the inbound and the outbound point of view and yeah.

Randy Franklin Smith:
All right, so what else can we say about security groups? Oh, this is interesting, both the source and the destination can either be a single IP address, could be a range of IP addresses. That’s the one that I showed you right here. Let’s get that window back over here.

Randy Franklin Smith:
So we’re in security groups, we’re specifically on a security group named database servers. And here, our rule has a source that is just a classic IP address range 10.43, but we can do some other interesting stuff. We can also specify a security group as the source or as the destination. Now, do you see how that works?

Randy Franklin Smith:
What it comes down to is security groups really give you two things. Security groups allow you to define a set of rules that are applied both inbound and outbound for a given set of virtual machines or NICs on those VMs. Since that constitutes a group of virtual machines or a group of NICs, we can also turn around and use that in the opposite direction or on the other side of the coin. Saying that, Hey, let’s allow inbound connections to port 1433 from all of our web servers and that’s what you’re seeing right here.

Randy Franklin Smith:
Now it’s irritating how they use this nasty ID code instead of giving me the name of the security group. But if we just remember E D6C, so remember we’re permitting inbound access to Microsoft SQL from source, and it’s a security group as you can see, it begins with SG and it ends in E D6C. Well, let’s look up here. If we can make this column a little bit bigger, seems like we can’t so I’ll just click on this thing instead.

Randy Franklin Smith:
Okay, 007, let’s go at it from that direction. Oh, I seem to have it pointed at itself, let’s change that because these are our database servers. We want our Web Front End servers to be able to access it. So Web Front End servers, there we go. Now we save that. So we’re permitting inbound connections to SQL server from security group 0183 and that does in fact correspond to Web Front End servers.

Randy Franklin Smith:
Now this is really nice because it allows us to abstract our security policy away from the literal IP address space. And we just define a logical set of computers called Web Front End servers. And then we say, Hey, Web Front End servers are allowed to connect to SQL server on my database servers. And Tim, that is a AWS example of what you guys refer to as intent-based security, we’re fair enough?

Sanjay:
Fair enough.

Randy Franklin Smith:
Of course it’s very limited, but I wanted to get that concept out to people because I know you’re going to be talking about it later, intent-based security. When we can say, I want my Web Front End servers to be able to talk SQL server to my database servers, that’s an intent. When I say I want IP addresses 10.42, blah, blah, blah, to be able to communicate on port 1433 to IP addresses, 10.blah, blah, blah, everything gets lost in the details then.

Randy Franklin Smith:
Okay, let’s see here. Quick question from Anusha, sorry to reiterate. Can the security group restrict the rule just one instance rather than a subnet? Yes, you assign security groups to instances you do not assign security groups to subnets. So let’s just go over here real quick to one of my virtual machines, one of my instances and… Maybe I’ll do it later.

Randy Franklin Smith:
I don’t get around super-fast and I think I need to go EC2 then I can see my instances. Yeah, so we’ll pick this particular EC2 and this particular instance or virtual machine is part of security group one. So you see, you assign security groups to instances not to entire subnets

Randy Franklin Smith:
Pearly says, is there a way to see a summary of all the access granted? Boy, that’s a nice segue for you later, Tim. All right, let’s see here. Now let’s compare and contrast security groups to network access control lists. So like I said, this is more like the firewall configuration you’d get on a classic router. And these are assigned to subnets. Network access control lists are the rules that you assigned to subnets.

Randy Franklin Smith:
Now, every sub-net has one and only one NACL you could reuse the same NACL to control access for more than one subnet NACLs are IP only, so you don’t get that nifty little option in the source and destination of specifying a logical security group. So it’s all just straight, classic IP addresses.

Randy Franklin Smith:
The other thing is that they are not stateful, network access control lists are stateless. So you’ve got to define mirror images of your rules, network access control lists support, not just allow rules but also deny rules. So that means the sequence of your rules becomes very important because if you want a deny to override a certain allow, it needs to precede that allow rule.

Randy Franklin Smith:
And so you’ll see in NACLs that you have row numbers and that’s what sorts these rules all together. So, this is very much like a classic firewall, wouldn’t you say Tim? Did I lose you Tim? That’s okay, let’s see here so what else? Security group only applies to that instance, whereas network access control is to plus the entire sub-net.

Randy Franklin Smith:
Let me just show you a quick network access control list. So here I have one named frontend subnet and I’ve got some very simple inbound rules. So this would be a subnet where my frontend web servers reside and I am allowing port 443 HTTPS traffic from the entire internet, but I’ve identified this one subnet in China that I’ve been getting a lot of problems with. And so I completely block even that one, port 443 from that particular range of IP addresses.

Randy Franklin Smith:
How do I know that it will override my allow? Because of the sequence. I gave it a rule number 90, which is lower than my allow rule and therefore it takes precedence. And so there you go Paul, there’s the NACL table. What you were looking at before was a security group but you’ll notice when I specify source and destinations, I don’t get the option to specify security groups here, it’s a straight classic IP address ranges.

Sanjay:
And it does Randy, it reflects more like a policy, those familiar with managing firewall policies are going to be very comfortable with the ACL list because that’s exactly what it is.

Randy Franklin Smith:
And sequence is big time important with most firewalls in that way.

Sanjay:
Definitely.

Randy Franklin Smith:
Yeah. All right, so let’s see here. I just want to visually put this together. So first of all, we have our virtual private cloud, which remember, that’s just an overall IP address space. And in this case, it’s that light gray rectangle that encompasses most of the objects on the slide. And my address space is 10.42. Now I have two subnets here, I have a frontend subnet and a second tier subnet.

Randy Franklin Smith:
My front end sub-net is 10.42.1, my second tier subnet that has my database servers and some second tier application servers is 10.42.2. I have a network address control list, NACL for both of those subnets, a different one for each of them. I also have a security group for my database servers and another security group for my application servers.

Randy Franklin Smith:
I probably should have also created a security group for my Web Front End servers up there as well. And that would allow me then to specify nice, easy to read English rules in my security groups between those three sets of virtual machines. Okay, then I have a route table and I have an internet gateway. Let’s just ignore the VPN thing for a second.

Randy Franklin Smith:
So everything in orange is a security control. The lowest level is the security groups that are attached to individual instances. Next level up is my network access control list assigned to subnets. And then I’d say the highest level are my route tables that say whether or not those two subnets can talk to each other or whether or not either one of those subnets can initiate outbound connections to the internet, or will any inbound traffic from the internet be able to be routed to any of those subnets. That’s all defined on the route table.

Randy Franklin Smith:
Now, what if you have more than one VPC, there’s all kinds of reasons why that could happen or what about getting outside that VPC to the internet, to your local network and so on. So there’s all these different ways that VPCs can connect to other VPCs or to other stuff. And there’s really four types of extra VPC, connectivity, connectivity to the internet, connectivity to your network back at your on-prem, other VPCs and other AWS resources like a storage account, an S3 storage account, just as one example.

Randy Franklin Smith:
So for the internet, we’ve already covered that that’s provided through the internet gateway and route tables, nothing really more to say there. And when you set up your AWS account, that stuff is created for you with default configuration, and you only modify it to the degree that you want to get more granular.

Randy Franklin Smith:
What about to your network? You can either do that with VPN connections or with something called Direct Connect. And that’s where you have a leased line, or you have some dedicated bandwidth from a provider that is accessible to you and is supported by AWS. What I have shown here graphically is VPN. And the way that works is you stand up on yet another AWS service called AWS-managed VPN and that creates an object in your VPC called a virtual private gateway.

Randy Franklin Smith:
So it’s like a VPN concentrator and it connects basically to your route table and you install one of many third party VPN gateways back on your on-prem network, configure the appropriate IPsec keys or whatever the credentials are. And you set up routing entries back on your on-prem routers so that traffic can be forwarded up to your VPCs and the cloud and those subnets and the opposite direction in your route table on your VPC, you set up routes so that your VPC subnets can find the subnets that you want to communicate with back on your on-prem network.

Randy Franklin Smith:
And so in this case, I’ve got those same two subnets, 10.42.1 and .2. And then my on-prem network overall address spaces 10.43. So once I’ve set up the VPN connection, then all I need to do is at my route table, set up a rule saying, Hey, anything bound for 10.43 anything, should be forwarded to my virtual private gateway. And of course, if I’ve been restrictive in my network access control list or my security groups, I would need to add some rules there too to permit the traffic, not in order to facilitate the routing, but just to permit it to flow.

Randy Franklin Smith:
Now, what if you have another group or another division with its own AWS account and has set up its own VPC? Or what if you have a business partner that has stuff up in the cloud and you need your Amazon cloud to be able to communicate with their Amazon cloud? Well, you can peer VPCs, and that’s basically like pulling a network cable from the two distributed routers of your respective VPCs and connecting them.

Randy Franklin Smith:
But of course, nothing physical is taking place. It’s really just an entry in your routing table. Once you have peered those two VPCs together, you set up the correct routing entries, so that 10.44 can find 10.42 and vice versa. Now, the big caveat here of course, is that these things need to not have overlapping IP addresses. So VPCs can be peered as long as they don’t have overlapping IP addresses. And they can be different Amazon accounts and even different regions.

Randy Franklin Smith:
How do you control traffic to other AWS resources? Because there’s a lots of other stuff in AWS besides virtual machines, right? And so maybe you want to use S3 storage from some of your VMs in your virtual private cloud, but you don’t want that storage accessible on the internet.

Randy Franklin Smith:
Well, it’s totally possible to do. You have to create an interface endpoint or a gateway endpoint, depending on the particular Amazon service in the case of S3 storage, it’s a gateway endpoint and that’s like dropping an appliance into your virtual private cloud.

Randy Franklin Smith:
Into your virtual private cloud and giving it a route, making sure that it can be routed to. Other AWS services use something called an interface endpoint. And so now you get this object that you drop into a specific subnet and it gets an IP address within that subnet. But now, the really cool thing is you’re authorized to systems, instances can access that particular AWS resource, but it’s not visible to the outside world.

Randy Franklin Smith:
Just want to give honorable mention to a few other things in AWS, and that’s a load balancers. So you have network load balancers that just does load balancing at the TCP level, but if this is a web application or a web API or anything that’s HTTP-based, then you’d obviously want to use an application load balancer because it does load balancing at the HTTP/HTTPS level and allows you to do lots of fancy things with the URLs and the host names in those HTTP requests. There’s a great comparison there at that particular URL for more info on that.

Randy Franklin Smith:
You also have the Web Application Firewall. Instead of looking at stuff at the IP level, this is looking at, again, those HTTP requests, breaking them down, looking for stuff like database injection, SQL injection as just one example, and providing security at that level. And then, they can be stood up in front of an API gateway, they can be stood up in front of an Amazon CloudFront, or they can be stood up in front of an application load balancer. And then behind that application load balancer, you’ve got instances or virtual machines. And of course, in this case, we’re talking about a whole different kind of firewall. That’s very URL-heavy.

Randy Franklin Smith:
There’s also something called AWS Shield, and this is distributed denial of service, DDoS, protection. Everybody gets AWS Shield Standard, it’s automated, and it’s just there. But, you can also pay for AWS Shield Advanced, which handles much, much, much higher bandwidth attacks and gives you a dedicated team.

Randy Franklin Smith:
What if you use Web Application Firewall and you find that you’re ending up with a lot of web application firewalls and a lot of shared logic between them? Well, I would say contact FireMon, but there is, we should mention, AWS Firewall Manager that you can use to manage those, but it’s only going to manage the Web Application Firewalls. It doesn’t manage security groups, or NACLs, much less does it manage firewalls that you have on prem and third party security appliances you may have in the cloud and so on.

Randy Franklin Smith:
And that’s all stuff that our sponsor FireMon does too. And that’s important because AWS is just one cloud. There’s Google, there’s Azure, there’s IBM, and firewalls don’t go away with the cloud. In fact, we’ve got more firewalls than we ever have. We got Windows Firewall on VMs, Linux firewall on VMs, we’ve got security groups, you’ve got network ACLs, we’ve got route tables, we’ve got web application firewalls, network virtual appliances. How do you keep all this stuff straight? And then what about all of your on-prem things that qualify as a firewall? That’s where I want to introduce Tim and Sanjay. And Tim, do I make you presenter first or Sanjay?

Sanjay:
Actually, Sanjay is going to go first, Randy and talk to the audience about what we’re doing to detect exposure. And you’re right, I mean, there’s so many different things going on in the cloud nowadays. As I said earlier, people are taking advantage of the many advantages that cloud provides, but there’s so many different applications that are being used on top of AWS or inserted into AWS, for the right reasons and stuff, and even the access and the authentication to those applications and stuff, and so it’s no wonder that … And even as you pointed out, it was interesting as you were going through the initial conversation there, you really kind of highlighted, without saying it, how easy it is to get AWS up and running. I mean, it’s almost as easy as swiping a credit card, paying for your account, configuring a few things and you’re up and running. You’re able to put data into a data bucket and start serving that data out.

Sanjay:
But in there lies the rub, too, and that can lead to possible exposures as we’ve seen, too. It doesn’t take very long for somebody to do a quick Google of S3 bucket exposures or data leaks to see what we’re talking about here. But anyway, I’ll let Sanjay talk about that, it’s pretty interesting what we’re doing here.

Tim:
Yeah, thanks Tim. I think a big part of what Randy was talking about, too, is just being able to understand some of the network configuration elements, and make sure you’re locked down there. There’s plenty of opportunities, because it is so easy to set up as you were saying, for misconfiguration or, again, even for people doing a Google search, as you said, to kind of discover some of this and start to try to break in and even compromise some resources.

Tim:
That’s really what we’ll talk about here for a little bit of time is around just the visibility piece. So, from our standpoint … Lumeta is part of FireMon, we work together. We’re really the piece that provides a lot of visibility to both security network teams around the infrastructure itself, but there’s a lot of reasons that it’s becoming more and more difficult to be able to do that. We’re focused here right now on the cloud, but I think a lot of what Randy talked about touched upon different areas, whether it’s networks are definitely getting more complex, especially we talk about mobile and IoT devices, but certainly the cloud, migrating towards hybrid cloud environments creates a lot of challenges, especially for security teams trying to get visibility into what’s going on there.

Tim:
As we discussed, the responsibility is shared between the on-premise security team and the provider security team to really make sure that things are protected. But again, when it comes to regulations and the final responsibility, let’s say, it comes down to the actual enterprise hosting their particular solutions within the cloud.

Tim:
You also mentioned something about risk from acquisitions, suppliers, and partners. As you are opening up doors for, again, suppliers as an example, to be able to access parts of your network, some of that hosted in the cloud, you’re now creating these other entry points that could be exploited for malicious behavior. Again, it’s another area that can be used to create a greater attack surface, and then just making sure all these technologies inter-operate together appropriately and work well together. Again, sometimes that can provide opportunity for misconfiguration.

Tim:
What we are seeing from our research, and I’ll talk a little bit more about this is we’re seeing over 40% of traditional networks even with existing security solutions, AWS-capable components that are meant to help provide visibility, there’s still a lot of end points and infrastructure that’s not being seen clearly and not visible, causing a lot of blind spots within particular infrastructure. And again, be able to track this stuff in real time becomes even more challenging.

Tim:
When we talk to security teams and certainly cloud operations teams, which can be separate in a lot of cases, especially the larger companies, we’re seeing that there’s this balancing between how do I make sure that security is in place, compliance is in place? I’m able to actually do that, but balancing with the rush to really move workloads into the cloud. I mean, the operational efficiencies, the scaling, and all the things that people move to the cloud quickly for are also causing challenges, for primarily security teams, in terms of both visibility into those infrastructures, but also being able to manage security policy within those infrastructures.

Tim:
So, again, it’s something that the more that we can do to help provide that visibility, and as Randy mentioned, too, in these hybrid cloud environments or sorry, multi-cloud environments where people are using more than one provider, it becomes very hard to do. We’re seeing where certain tools are being opened up by Amazon or by Microsoft specifically, but how do I see everything together at the same time from a, I hate the term, but a single pane of glass? All that visibility, especially from a security standpoint is meant to do, mainly, get security teams to find any sort of opportunity for a threat, any sort of suspicious behavior, as soon as possible.

Tim:
The earlier I can see, the faster I can see it is important, but it’s also do I have the context and information I need to be able to remediate quickly? Whether it’s an application bottleneck, whether it’s some sort of odd movements, whether it’s I see suddenly a path being created in the Internet that I didn’t expect. We’ve got these public networks that we’re talking about, or public openings out to the network that Randy was mentioning, where I’m creating direct links from cloud environments to the Internet, a lot of organizations don’t want that. They want it to still go private back to their VPN and then go through a bunch of security checks and then go back outside to the Internet. So this is something that, depending on your policy, you may want to restrict that movement, and it’s something that, if you start to see that happening, it’s indicative of maybe an attack coming up.

Tim:
You know, again, when we’re talking about security within the cloud, we want it to be baked in as much as possible. And when we talk about being baked in, that is running fairly well in the sense that people are baking in security, security teams are pretty strong, the great visibility on premise. When it goes to the cloud, it seems to be, again, where it’s not … It’s much more limited and it’s not baked in as early and as often as it should be. So being able to make sure that I’m getting that scale, being able to optimize the cloud infrastructure, make it flexible, sometimes we let security take a back seat to that. And again, this is where we’re noticing attackers and different teams outside are starting to see that maybe they go and address the cloud and start to attack the cloud more actively, because those security controls aren’t in place or it’s very difficult to see those as well as they should.

Tim:
I think we’ve talked about it quite a bit, Randy and Tim have both talked about how the responsibility is shared and really where that sits into being at the end, at the doorstep of the enterprise that’s actually working within the cloud environment. And the real question is what’s the impact there? How does it impact the rest of the enterprise, even when you’re talking about someone exploiting something within the cloud, is that something that can get back on premise and even certain sensitive data on premises can be at risk? So again, the cloud is definitely being used as a attack surface that can be a little bit more exploitable in some ways, despite all the security controls and all the reassurance from some of the cloud providers.

Tim:
There are a lot of things that have to be considered as part of that, some of it is shadow IT, and we’ll talk a little bit about that. Shadow IT’s a big problem, and talking to different customers where they’re seeing a lot of that activity occur mainly from DevOps, but they’re seeing that cropping up in cloud environments, because it’s so easy to spin up resources, as Tim mentioned.

Tim:
Certainly misconfigurations can be an issue, and in general, how do I know that I’m managing all the vulnerabilities that are in that environment, because it is very hard to be able to determine what systems are vulnerable, identify all the systems, be able to understand how the network is operating. Certainly see things like leaks, those are all areas that, again, we’re getting better on premise, but at the same time the cloud, it’s very new in those environments.

Tim:
Container security is another area, as well, that we’re seeing more and more activity in the ability to be able to have visibility into containers, be able to understand how they’re operating, certainly see any vulnerabilities that can introduced. It’s an area that’s starting to grow, and we’re going to see rapid growth that especially this year, but in 2019 we’re going to continue to see that growth.

Tim:
So, when you talk about gaps that exist, there’s quite a bit that we see in our research over time, I’ve got a few verticals that are kind of listed there, but this is the case on premise. And it certainly is something that extends further into the cloud, and is much worse, is that when you’re talking about end points, and end points means any sort of IP enabled device, printer, virtual machine, it doesn’t matter what it is. It’s got IP address, that’s really what we talk about as an end point here. We see that a lot of customers, especially … We’ll say these are the ones that actually manage or monitor, so they’re basically the end points they know about. When you install something like what Lumeta provides, what we see is we see a huge gap, and many customers have different solutions in place, whether it’s Sims or NetFlow collectors, et cetera, aggregation devices to be able to understand cloud data, but we’re still seeing a huge delta between what’s being actively monitored and managed, and what actually exists out there at a given time, again, real time.

Tim:
This is what we call the endpoint visibility gap. These are the average numbers across these different verticals, but again, we’ve seen much higher in some cases. We’ve seen some, especially in cloud environments combined with on-premise, we’ve seen over a hundred percent, which is amazing to think about that, in terms of managing and monitoring infrastructure and securing it, that there’s so many devices out there that just aren’t are known, and really, again, watched carefully, which means how do I patch those systems? How do I make sure I have endpoint protections on those? How do I make sure I’m scanning them for viruses? Whatever the case is, is that those are kind of left out there, and I’m not able to really secure them properly.

Tim:
When you’re talking about unmanaged networks, again, this is a case where I’m not able to crack into that particular network, I don’t necessarily have the visibility into it. It might be that it failed the polling intervals, over time it’s dropped out of my asset list. This is where we see whole networks that are just missing that, again, aren’t being actively managed, which is, again, a huge number in some cases.

Tim:
Unauthorized or unsecured forwarding devices, this was something, again that Randy had talked about, where if I’m configuring ACLs or configuring a switch or router, we can see where some of the switches and routers are left open to manipulation. I can create forwarding tables, create them as an illegal forwarder, create an ACL that maybe allows traffic to be exfiltrated. Things like that are where we see these unsecured, unauthorized forwarding devices that shouldn’t be there, and certainly something that is a huge consideration in the cloud, especially when we’re talking about misconfigurations.

Tim:
Known but unreachable networks tend to be things that don’t respond to traditional SMP pings, things like that. Again, this is something that we see sometimes happens. Something has been configured incorrectly, maybe a firewall has been configured to block this type of information, and yet now I’m unable to see those networks that exist on the other side of that firewall.

Tim:
And then the big thing that we’ve seen a lot of attacks and customers in general is leak paths. What we call leak path is basically an unauthorized communications to the internet, or even across segmentation, across firewall enclaves. So this is where I want to protect certain assets using a firewall, certainly a perimeter firewall going outside as an example, and yet we find these leaks that have been created for various reasons that are left open. And these are ones that are open based on, again, us being cold going in there, determining what leaks exist, and we can see these leaks can be a huge problem.

Tim:
You can see the numbers that are listed here. Very often, a malware attack or ransomware attack will not necessarily create a new leak path, we’ll see an existing one that was left open, and they’ll use that to exfiltrate data or share a ransomware keys or whatever it is, mainly because they know that that leak path is not being actively monitored. It’s not really known, or people aren’t paying attention to it. And again, they can use that to be more effective in hiding what they’re doing.

Tim:
Let me just talk quickly about Lumeta Specter. Lumeta Spectre is our solution that is part of FireMon now. What we talk about is the first fundamental thing that you need to do is just eliminate these infrastructure blind spots. That’s being able to discover things that a vulnerability scanner can’t do, that a NetFlow collector isn’t able to see, that traditional network access control doesn’t really focus on in terms of finding everything, even across shadow IT or unknown or rogue environments. We see even virtual machines can sometimes be created by an attacker to be able to hide their activity, and certainly they’ll spin up a VM, do some strange activity and then close the VM quickly, and they can do this over and over again. So being able to see those different pieces of infrastructure as they’re created is important.

Tim:
Certainly important when you’re talking about shadow IT. DevOps may create a bunch of virtual machines in a cloud environment, are those adhering to the security policy? I don’t know they exist out there, how do I make sure that they are, and we’re able to manage them effectively, and certainly protect them against attack.

Tim:
We’re talking about dynamic network changes, most solutions out there will detect change based on polling, or they talk about continuous monitoring. Being able to see changes in real time, especially when it comes to cloud infrastructure, is critical because they change frequently and to optimize how things are working in the cloud to get that scale, and maybe adding new virtual machines and maybe moving them around as an example, certainly they would be creating a new network paths between different areas within that particular VPC, being able to see all of that is critical to be able to, again, make sure that they’re adhering to security policy, but also to see if there’s a network anomaly, some sort of attack pattern that’s occurring, or an early indicator or some sort of compromise.

Tim:
We talk about really having that visibility, really being able to see things in real time means now I can identify new leaks that are being created and lock all those down. But without that visibility, without that real time monitoring, I’m not really able to do that, and identify things like unauthorized movement, where a new path is being created between maybe two areas that are restricted within a particular network, and I don’t really want talking to each other.

Tim:
And then the last part is more traditional security activity where I’m looking for suspicious network behaviors as an early indicator of compromise, whether it’s a virtual machine that’s been hijacked, command and control activity, again maybe I’m sharing encryption keys across a leak path that’s been created, those types of things can really help security teams get ahead of an attack and certainly provide them with a network context to help remediate more quickly as well. Very critical, especially in cloud environments where I’ll have multiple teams working together. It could be someone who’s obviously managing the cloud operations, the network team, security team, maybe even a desktop team, the more network context I have around endpoints, around networks, around where things are occurring, the faster I can remediate.

Tim:
We talked about having a single view and the ability to look at things in a multi-cloud environment, in terms of I have multiple providers, I might have a vCloud environment that’s part of my infrastructure. I might work with Amazon or Azure. I may have multiple environments, IBM or Google. Being able to see everything from a single pane and be able to understand from a central location well, here’s my on-premise enterprise and here’s the extension into the cloud, but here are all the assets there, here are all the changes there that I need to look at, need to know.

Tim:
That’s critical to be able to secure the infrastructure itself, and at Lumeta we work with a lot of different security vendors also, so that if I need to deploy an additional, say, EDR solution in the cloud, or I need to put some Nexion AV on a set of end points that I wasn’t actively managing before, we can work with some of those vendors to make sure they know that, hey, this new asset has come up, I might want to do a vulnerability scan on this new VM that’s come up here, as opposed to waiting until my next scan interval and make sure that it’s protected. So these are the areas that we can really provide a full view on premise that extends fully into the cloud, and visibility really starts out in helping to manage the security policy going forward.

Tim:
I’m going to try and go through some of these quickly to give Tim some time to talk, but one of the things that is critical, as I mentioned, is being able to look at multi-cloud environments, but also being able to see any sort of shadow IT created. I’ve talked to many organizations where one of the biggest concerns they have in terms of being able to track things in the cloud is in their DevOps team will create a whole bunch of resources in there, not necessarily tell IT about it or even CloudOps about it, because it is so easy to spin some resources up. And this is where the ability to identify these different resources and go, hey, this stuff going on out here, what are all these virtual machines, and what’s this new VPC that’s been created without understanding what those are and where they exist, it can be very hard to be able to lock them down and secure them.

Tim:
Hackers will take weeks and months to find out what are the most vulnerable assets and areas in the network that I can exploit, so they take a long time to really figure that out. They may go in there and find that … They notice that this DevOps VPC that’s been created without knowledge of the main IT team is something that has been left unpatched or is vulnerable, it’s not being actually managed actively. This is where identifying all the VPC instances, being able to understand all the hosts within those VPCs, and then understand all the different forwarders is critical to being able to identify the infrastructure and lock it down. Very useful for a SOC team.

Tim:
When we talk about leak paths, again, this is a replication of some of the data we had previously, but being able to see if a path exists from a cloud environment to the Internet is something I may want to prevent, but certainly making sure that any new leak paths that might be created is potential for maybe a compromised system that is starting to contact a known malware site, or even going as far as exfiltrating data or trying to install new malware and spread the infection within the cloud environment and certainly through the VPN tunnel back into on premise.

Tim:
This is where being able to lock down who can talk to who is very important here. You may have policy that dictates, hey, I want to make sure that my financial database is not talking to my engineering servers is something where I want to make sure that policy is maintained. Identifying leak that suddenly springs up between those different areas is something that’s critical, both on premise and in the cloud.

Tim:
This is where Lumeta can deploy Scouts within those environments, and it’s our extension of our capabilities, where again, they might be protected by our firewall, I want to be able to have some visibility in that area that I may normally not get, especially when we’re talking about in the VPC environment.

Tim:
This is just a quick case study before I turn it over to Tim. This is an actual customer that we basically sold into this year. Their biggest concern was that they had an incomplete view across both their headquarters, but also the remote facilities. They had different offices in different areas across the state. They had moved some of their critical database information into the cloud, but they weren’t really able to detect any sort of new malicious connections being created within the cloud environment, something they were concerned about from an audit standpoint. One other thing that they were very, very adamant about is they didn’t want any new agents, or any sort of heavyweight components developed in the cloud. They didn’t want to have security technologies that are deployed on a per VM basis or anything like that. So, again, they were very adamant about that, they had too many agents to manage as it were.

Tim:
The way that Lumeta is deployed in general is that we actually can simulate being a switch or a router or VPC in that environment, and so we participate in the network, but we’re not sitting in a VM … Sorry, on a customer VM, we’re kind of sitting in a VM within that environment, just able to pretend we’re part of that environment and be able to use different techniques, to be able to do discovery and real-time monitoring. So again, we’re very lightweight in what we do, no agents required.

Tim:
As I mentioned, there was some concern, they had some developers there that were creating some shadow IT environments in the cloud. It’s a very common problem. With Lumeta, we’re able to provide that full-

Tim:
Very common problem. With Lumeta, we’re able to provide that full end-to-end visibility from a single dashboard, but also be able to provide alerting from a visual dashboard to say, “Hey, this resource suddenly turned red. There’s some sort of problem there and you need to go see if there’s maybe a new leak path that’s been created there.” This is where we can do real-time monitoring from that dashboard and be able to dive into that particular host and look at a particular host and say, “Okay, well, this host exists here. This IP address, this is what its operating since it’s running.” And you can go in there and basically determine whether it’s something that needs to be quarantined, as an example.

Tim:
Again, providing that early warning is critical. In this case we did see some Tor traffic running around and most people don’t want that traffic there. It tends to be used to hide the list of activity. So we did see some of that going on within that environment and calling out to external devices directly from the cloud to the internet. Again, an impact we provide is this real-time detailed mapping the entire network, including any IP asset send to the cloud. We did find 22 existing leak paths. And this was both combined the on-premise and cloud, not too many, not too bad, but we did see in both areas. And when talking to the customer they had had quite a few contractors there. And one of the contractors apparently left a few of these connections that were open. You know, that was one of the things they did reveal to us. So, that was something where they were able to lock that down.

Tim:
And that that contractor was long gone. He wasn’t there any longer from what we understood. So this is just something that kind of got left open, again, locking those down were important and we continue to be able to detect any new things that were going on there. Again, a lot of the context information provider useful, especially for remediation. So we can shrink the time and security needs to remediate a breach because they have the ability to talk with the network team or the cloud team and say, “Here are the assets we found. Here’s the actual issue that we saw in real time. And so now we can go address it quickly and work together through ticketing or whatever, whatever mechanism is needed to be able to stop the particular issue.” So again, this is where a limiter can be very useful in working with those solutions.

Tim:
So with that what I like to do is turn it over to Tim. And Tim will definitely talk about this visibility as the precursor to really being able to really work on providing manage your security policies more effectively at a global level. So let me just switch it over to him really quick.

Sanjay:
It really is. We have a saying at FireMon, “You can’t manage what you can’t see.” And also it’s very hard to protect what… There we go look at that. It’s very hard to protect the unknown as well. So it goes directly correlates to what Sanjay is talking about there. It’s interesting as we go through this, I mean, the world has changed and people are taking advantage of this new technology to be more competitive in business, but there’s no speed limits anymore. And so we see probably the business has accelerated and over the last three, four or five years, eight X, what it was say three, four, five years ago. And so, as it takes advantage of these things, but we’re moving so fast that our ability to secure those applications, we’ve moved past our ability, I guess.

Sanjay:
The speed at which we’re deploying applications in the cloud, the speed at which we’re the business has accelerated. We haven’t been able to keep pace with that acceleration as it relates to securing those applications. And so, for the most part it’s not even hacking that we’re talking about. It’s not even the typical nefarious activity that you might expect where hackers come in and they use some creative plot for getting into the network. They’re just out there looking for open things. They’re out there looking for open exposures. They have programs that are surfing and looking and examining cloud known area, address ranges and stuff. And they’re finding these exposed data buckets. Every one of us, probably everyone on this call today has had their data exposed. If you’re familiar with the exact, this breach that took place here, not too long ago, over 340 million consumer records, to put that in perspective, that’s about two terabytes of data that was exposed.

Sanjay:
And very personally… While it wasn’t really credit card type stuff, but it was very personally identifiable information. And probably my stuff is out there. Sanjay, your stuff is out there. You know, we were all, probably all in this database, this marketing database from executives, but it was just the lack of configuration. It wasn’t that they did anything necessarily wrong. It’s either a lack of a lack of knowledge on the configuration of how to secure that database or a lack of security controls. And so, anyway, these data breaches can happen. These data exposures, data leakages can happen and large amounts of information can be made readily available with no hacking involved there. And then we still got complexity to deal with. Complexity doesn’t go away just for probably jump into the cloud the problem with complexity, the number of rules that we have to manage, and that the devices that we have to manage, and the access to those devices that we have to manage, all of that goes away.

Sanjay:
And it’s all going up. And the problem with that is that the resources that we have at our disposal necessary to focus on that problem, those resources have. And so we have to look… Haven’t gone up as well. So we have to look for a way to give our people, give our resources, the tools that they need to become more effective and efficient. And given that we’re not adding more resources and that there’s a shortage of highly skilled technical resources out there. So we need to way to automate some of those things, to make our big… Give them the tools that they need to more effective. And that’s very important. And then, I’m not going to go into this hybrid, multi private, Randy talked about this, Sanjay talked about all this, the different cloud providers that are out there.

Sanjay:
You know, there’s no doubt that we’re in a new era, we’re in a new world right now. I’m at a security conference today for the oil and gas industry. And we’re talking about industry 4.0, and we’re talking about the gap between IT and OT and control systems and control systems moving into more centralized visibility, as opposed to decentralized visibility and stuff. And there’s a lot of things that have to happen before that can happen in security is at the forefront of that. Security has to be the forethought security by design and default as is stated by the new GDPR regulatory mandate. Security by design and default has to be the first part of that. And so very quickly here, I’m going to go through what I call the three tenants. And this is what one of the reasons that we’re so happy to have Lumeta on board as part of our solution portfolio.

Sanjay:
And that’s helping us to give better visibility across this ever-changing cloud environment. It’s not just the cloud. We still have to keep our visibility. We still have to keep our eyes on the enterprise as well, right on the on-prem stuff, we’ll call it brownfield, but anything that’s going to greenfield going into the cloud, new things, new applications, resources, and assets that we’re deploying into the cloud to take advantage of business acceleration, for whatever reason we still have to keep our eye on that. What makes that even more daunting or challenging of course, is that it can be very dynamic too. When we start talking about… Randy talked about virtualization of assets, virtualizations of instances and things like that of applications. But then also we have Sanjay talked about containerization. And all of these things can be very, very dynamic, can be changing, not just on hourly, but sometimes but on an hourly basis, not daily basis, but hourly basis up to minute basis.

Sanjay:
So everything that we do has to be two things. One it has to the continual first and foremost. It’s not just a one-time thing. We’re not just going through here and doing it and we’re one and done. It’s a continual exercise that we have to go through to understand what is exposed. What is the unknown? What is out there? What is new? What has changed? What is move? And how our security controls being applied to those things, are we adapted? Do we have adaptable security that applies to these things as they change as well. And so all of this has to be real time. And so, the first thing is to look at the threat land landscape. First and foremost, we have to have good continual visibility of where our assets, resources and applications are at and the security around those things.

Sanjay:
And I won’t… Due to lack of time and respect for your time. I’m not going to go into security intent too much, but we believe that the future will hinge on security intent. Being able to make sure that our security controls do follow our resources, our applications, and our assets as they change automatically. And so vulnerability management, looking at the threats landscape, being able to understand if a threat actor came in. A well-known threat entry point, how far they could get and what could be exposed. Those are really important questions that we have to ask ourselves to understand those resources that we’re putting in the cloud and on-prem are they exposed? Are we correlating our known vulnerability stance against what our access, what our compensating controls allow?

Sanjay:
And then the next part of that is making sure that we have compliance. And I’ll say this, if you don’t remember anything else that I say today, if done correctly, compliance can be that which allows us to technically enforce our security policies. It allows us if we can relationally link our written security policies to what our compliance should look like. And yes, I know you’re going to be driven by regulatory compliance initiatives like PCI and FISMA and NERC and SIP and GDPR, and all those ISO 27,000, 9,000, on all those different things that are out there, but also compliance can be used, not just as a check box that we have to comply with against a regulatory mandate, but also as a best practice for us. There’s no silver bullets out there and compliance can be a great place to start for helping us to really try to incorporate those compliance initiatives and align them with our security policies as well.

Sanjay:
And then using that as a way to technically enforce our written security policies, dynamically real time on a continual basis. Very, very important. And then last, but certainly not least it’s having that centralized view into all of this as it’s taking place. Even there’s so many different devices out there. There’s so many different security vendors that are offering. One of our attendees asked today if we supported… What was the question here? I’m trying to go back. If we supported another cloud vendor, I can’t see it here. I’m trying to scroll it up. But we do today. We’re supporting Amazon, and Microsoft Azure, and Google cloud and IBM cloud. And we’re working aggressively, VMware. There’s so many cloud compute providers out there. Even if you start looking at Rackspace, Red Hat or by IBM recently, Oracle cloud and Adobe and Verizon cloud.

Sanjay:
And these are all places where we can have data exists. And so we have to bring all of this into visibility as we’re deploying either our own internal data or our customer data onto the cloud. So we need that centralized view across these deployments of data. And so what you need is we need a continuous security monitoring platform that incorporates the security landscape, understanding what that security landscape is at any given point in time, how are we met? How are we complying, and how are we making sure that our controls are effective? How are we making sure that the security that we’ve deployed is really actually protecting those assets, resources, applications that we put out there? And do we have a centralized view with actionable data? I really like what Sanjay was talking about, because what he was talking about there is giving you actionable data in the event of a nefarious activity or in the event of something suspicious taking place.

Sanjay:
We have actionable intelligence that we can act on, which is so critically important today. It doesn’t do us any good if we don’t have the context behind it. So we need to look at that. So just a quick snapshot of the FireMon portfolio here. I’m not going to go into detail about that. Here’s what I would say to you guys today that are still hanging with us, is if you’re going down this digital migration path, if you’re adopting cloud aggressively, if you’re putting data out there and you don’t have confidence in your security controls, give us a call, give us a ring, let us help you with that. Let us show you how we can help you gain better visibility across your environments, across your infrastructures, your security infrastructures. We support about 50 different permutations of products today, and that’s growing weekly, monthly, for what we support. So we’d love to talk to you and show you how we may help you gain better visibility across your cloud deployment.

Sanjay:
One last thing that I would note here. I know I said, if you forget, if you don’t remember anything, remember this, I’m going to say it again. If you don’t remember anything else that I said, remember this, I think also as you’re looking at your vendors for the future, you want to make sure that they have a robust, open API set. Because I think the future for bringing up the total value of your applications that you’re using both… And that’s not just for… I know we’re talking about network security today and network security in the cloud, but I’m just at the server level, at the desktop level, at the network and at the cloud level, at the backend level, having robust APIs, that can allow you allow your vendors to intercommunicate with one another can do nothing, but raise the total value of your security solutions going into the future here.

Sanjay:
So make sure that the vendors that you’re choosing have a robust API story for you. And that’s all I’m going to say today. I’m going to turn it back over. If we have any questions, I think we may have, actually, I think we’ve went over time, but we’ll try and back over if we have any other questions. Randy.

Randy Franklin Smith:
Okay. And we do have some questions for you, Tim and Sanjay. First of all, what access does my VPC need to allow for FireMon?

Sanjay:
So, actually for FireMon and FireMon can fit well, we can set in the cloud, we can set outside of the cloud. We can set in the data center. It just really… We have a port definition guidelines to show you exactly what ports need to be open to allow us essentially, we’re looking at log data coming from those devices that we’re monitoring. We parse that data real time. As I said, everything we do is real-time. When we detect a change, a configuration change across any device that we’re monitoring, we immediately do a differential comparison extract that delta and give you a really nice who, what, when, where, why, report so that why that change happened and where it happened and where it happened, all that good stuff. But better yet now we have that newly modified configuration that we can store in our database and we can now audit that configuration.

Sanjay:
Let’s face it change, happens all the time. But the real question we have to ask ourselves is, was it good change or was it bad change? And so we need to be able to monitor for that change real time and make sure that that change is good change. So it really depends on where the device is set in the network where FireMon is sitting in the network, but we have guides that can show you what ports have to be open for us to get access to what’s pretty straightforward.

Randy Franklin Smith:
Okay. Gary says that… He says, does AWS or Asher’s infrastructure, this is more for me, allow breakout a particular traffic flow so that they can be routed to a centralized instance for network intrusion prevention, DLP, or other functions? And so, Gary, yeah, there’s nothing in my opinion, specific to what you’re talking about. Like any feature that says, route data through my network intrusion prevention system, but you can stand up those things in your cloud. And there Azure and Amazon have a marketplace for third-party security solutions. So if you’re a big vendor, X firewall user, you can use that same firewall in the cloud. Or if you’re a big vendor B, now we’re network intrusion prevention or DLP user, you can use generally that same technology in the cloud, and probably not even have to install it yourself, but it’s probably already there in the marketplace.

Randy Franklin Smith:
Gary also has question, I guess more for Sanjay. How does Lumeta work? How’s it deployed? He says, you said we pretend we’re part of the environment to do real-time monitoring. He says that sounds worth understanding. Go ahead.

Tim:
Sure. No, I understand. So basically we were deployed as we’ve got, what’s called a command center and that command center is basically we’re going to run a virtual machine. The way it participates in the network is that it would kind of simulate as if it was a router or a switch. And it would start to talk to the adjacent router and switch and then from there start to look at the routing tables there. It would basically understand the adjacency set around switching slowly, we call it recursive network indexing.

Tim:
It slowly build the profile of all the network infrastructure, especially the routing and switching infrastructure throughout that environment. As it does that it’s also seeing all the devices that are communicating through that router and switch, and they can also do credential lists scan of that particular endpoint to provide some of the details I mentioned, like operating system might be addressed based on reports, things like that that you’d want necessary credentials for, ’cause we don’t really want to go and hammer the end point, especially a virtual machine.

Tim:
But we can start to do that there. And we have what’s called active and passive listening techniques. As we participate on the network where we’ll listen to things like routing updates that are occurring to see how devices will change or network topology changes occur will basically see certain traffic that’s going through like broadcast traffic and figure out if there’s a new announcement from a new device. But there are other techniques we use in there that are somewhat patented on our part. We’ll also add some passive, sorry, some active techniques where we will send out small little test package occasionally. And those packets are really designed to elicit a specific response, especially from infrastructure trying to stay hidden.

Tim:
So we have some more elaborate techniques beyond. Again, pings and things like that that we use and we have some analysis of the traffic coming back and the response is coming back and some, one way that we can find all the shadow IT or unmanaged or even things are not only responsive on the network too. So it’s talking to the network and this sort of capacity we’ll find it, but we use this combination of passive and active techniques in our analytics in there to be able to look at the information going by or coming back is how we’re able to really do that discovery that no one else can do around things that want to stay hidden sometimes. But again, the way we do that, as you participate in the network is if a network element, traditionally a router or switch sitting in that environment.

Randy Franklin Smith:
Cool… Okay, cool.

Tim:
Sorry, just one other things… So we directly connect with the APIs in a cloud trail for example, for Amazon, AWS, and also we connect directly to Azure. It’s a way that we’re able to have that full visibility instead of just listening. We can actually start to do some more techniques in there that we can do just like we do on-prem. So this is where we can always kind of operate in those environments, but now we’re really able to go and plug into those to get extract more data, to really understand the network environments and all the devices and virtual machines that are connected within that environment. So that’s how we sit there.

Randy Franklin Smith:
All right, awesome. I think that answers our questions and that is our time for the day. Guys thanks a lot for making today’s training possible and you’ve got two very unique and cool technologies there. Love it. So thanks a lot. And yes, we will be sending out a copy of the slides, a link to that. So stay tuned, look for that in your email. And thank you everybody for spending time with us today. And we hope it was valuable for you. We’ll talk to you again soon, but bye-bye for now.

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