[Start of recorded material 00:00:00]
Ariful: Good morning everybody. Thank you for joining this webinar today with Aporeto. My name is Ariful Huq, and I lead product management here at Aporeto. I’m just going to give it maybe a minute or so for folks to join. So just give us a minute while we have some folks join as well.
Good morning. Thanks again for everybody to join this web conference today. My name is Ariful Huq. I lead project management here at Aporeto. What we’re going to talk about today is cloud security gaps. So we’re what we’re going to kind of address is some of the gaps that we see in talking to a lot of our customers. What are the gaps they actually have when they go and adopt cloud, specifically around security? We’ll talk about some of the ways to solve these problems, and then we’ll kind of conclude this session with how we’ve solved these problems at Aporeto with some case studies and examples.
Right, to start with, I want to go over the journey that a customer typically goes through when they adopt cloud. So when you think about your applications in a private datacenter, in a traditional data center, you typically have a north-south firewall. And behind a north-south firewall you kind of have a large IP parameter where your applications are. And one of the problems that’s very common in this space is lateral attacks. So if a specific workload gets compromised in this environment, you have the potential for large lateral attacks because the IP parameter is very large. Now this problem only becomes worse as you move towards cloud. Because what happens is – and as I’m showing you in this illustration here, the first inclination is to treat your public cloud infrastructure as an extension of your datacenter.
And the way customers end up doing these sorts of things is they end up building VPNs, tunnels. So they do some sort of tunneling, some sort of FDN overlay that they may be building to actually kind of treat the public cloud infrastructure as an extension of their datacenter. So the problems that we were facing earlier in the traditional datacenter – they only extend into your public cloud infrastructure because now what’s happening is you’re actually increasing your IP parameter. Because you treat your public cloud infrastructure as an extension of the datacenter. And you couple that with – when you move to cloud you want to adopt microservices.
So now you have an explosion in the number of applications because you’re going from monolithic to microservices, so you have a larger number of applications. You’re adopting containers, which are kind of ephemeral in nature. So that kind of exacerbates this problem of the lateral attacks. Because it’s really hard to kind of control ephemeral workloads, especially when you have a very large IP parameter. And you add that with microservices everything is exposed to an API. So lateral attacks towards an API where you want to exfiltrate data potentially also becomes a problem. So really, as you go through this journey, the adoption of cloud kind of exacerbates this problem of lateral attacks.
So what are some of the challenges that exist when trying to solve these problems with existing network security technologies? So the first one is very common. You typically try and put in a third-party firewall. And this example that I’m showing you here is something that I’ve taken, actually, from a firewall vender. And what they typically kind of – what you have to do to actually adopt this kind of technology is you have to put the firewall in your public cloud infrastructure. Now you have multiple availability zones. That’s typically how you do redundancy in a public cloud environment. And this example here is kind of showing you – if you understand the illustration – it’s kind of AWS-specific, but it actually applies to all the clouds so now you have multiple availability zones for redundancy.
You have to consider where to deploy this firewall. What you really have to end up doing is you have to deploy multiple instances of firewalls across multiple availability zones for redundancy. And you have to ensure that all your traffic goes through this firewall before it goes – either for east-west traffic segmentation or even north-south, to protect north-south traffic. And then you kind of want to consider things like auto-scaling, because if for instance the firewall is running out of capacity you want to auto-scale firewall instance as well. And if you want to do things of that nature then you have to think about, “Okay. I have to have a load balancer that I use to load balance across multiple firewalls. And that traffic has to again get load balanced across my applications.”
So there is an overwhelming amount of complexity to integrate a parameter security model into your public cloud infrastructure. Because it is not the right fit. Typically when you try and put in a third-party appliance that the cloud provider is not offering to you, you kind of have to go figure these things out yourself. And then you have this notion of using kind of a micro-segment. You’ve heard of many vendors out there talk about, “Let us help you do network micro-segmentation.” So what that means is to kind of shrink the IP parameter you only think of the IP parameter between two workloads.
And when you do things of that nature – let’s take an example. If your workload is in an auto-scale group, it replicates. It gets re-hosted because it’s moving. Then there’s a problem because if you’re using an IP parameter to segment these two workloads, and your workload gets replicated, you have new workloads popping up, or it gets re-hosted. It gets re-hosted to another host. How do you rebuild this IP parameter? The only way to do it is if you’re using IP addresses, you have to go build in new rules. So you have to constantly add new rules to your ACLs to solve this problem of segmentation using IP parameter or micro-segmentation using IP parameter. Couple that with containers.
The nature of a container is you have multiple containers on a host. And in most public cloud infrastructures when you apply things like security groups and network security groups, they typically apply to a host. Now you have multiple containers and a host. How do you segment every single container? That becomes a very difficult problem to solve as well. Because what ends up happening is you have a single security group or security policy that applies to a single host, and then you have multiple containers, so you have no way to segment it across multiple containers. And if one of those containers gets compromised you have free roam – the ability to freely lateral attack other containers on the same host.
Now the last challenge is around visibility. And this is important because visibility gives you an idea of what’s actually happening out there. What is my application communicating with? Is it sanctioned communication? Is it not sanctioned communication? What I have is an example of an application that is across multiple cloud regions, has a dependency with something on prem. What we typically see customers try to do is you may use things like VPC flow logs or some sort of a flow logging mechanism in your cloud provider. But on prem you don’t have that ability. You may end up using something like IPFIX as a way to get flow visibility.
Now try and imagine coupling all this information together to figure out, “Hey, if my frontend application is making a call to some sort of backend sitting in my on-prem data center, how do I get visibility to this sort of communication? Or how do I get visibility if my database is replicating across multiple cloud regions? Because the flow logs and the way this information is created is disparate across all these environments. You really have no idea of how to correlate these types of information. So that’s a huge problem in terms of network security with existing technologies that are out there.
So with the challenges being highlighted, let’s talk about, “What is a better way to solve this problem?” And you’ve probably heard of segmenting every workload to stop lateral attacks. I’ve talked about it. There are a number of other vendors out there that have also talked about this problem. You essentially solve these problems by segmenting every workload – micro-segmentation. There’s a lot of terminology out there. With Aporeto our three is slightly different, and we’ll kind of explain. In the next set of slides I’m going to explain why is this different, why we’ve decided to solve this problem this way and what our customers think about the way we’ve decided to solve this problem.
So the theory here is you assign every workload with cryptographic identity. That’s important because identity is critical to any authentication and authorization mechanism you put in place. And at the end of the day a policy is supposed to allow you to define this authentication and authorization logic. So the first thing we do is we give every workload a cryptographic identity. Once that is done you define a distributed policy, and that policy is enforced in a distributed manner but defined centrally. And we’ll show you some examples of how we can define this. And as a result of this, what you do is you authenticate and authorize all communication. And at Aporeto the way we do it is we authenticate and authorize communication network as well as the API layer.
So the sum of this is every workload now authenticates and authorizes communication with anything else it’s trying to talk to. And that allows you to isolate every single workload, independent of the infrastructure over which that workload operates in. Because as you can imagine, I’m not talking about IP addresses here. So it doesn’t matter if my application is sitting behind a load balancer or a [NAD] gateway and my public cloud infrastructure. Or it’s sitting in my on-prem data center behind a north-south firewall. All I have to do is make sure that these two workloads authenticate and authorize each other using cryptographically signed identity, and I don’t have to define any sort of ACLs to define this level of segmentation. In fact, using ACLs to define this level of segmentation is actually very difficult. So this is kind of the fundamental of how we solve this problem.
What is cryptographic identity? We talked about it. It’s critical to understand what it is. So let me just spend a couple minutes explaining what we actually mean by cryptographic identity. What it is is it’s actually a dynamically generated identity for your application. So what you can do is you can introspect. For instance, if you’re using a Docker or Kubernetes orchestration capabilities to orchestrate your container environment, you can introspect these orchestration tools to figure out things like applications tags and labels. These are very common things that you use in Docker and Kubernetes environments. If you’re not using Docker or Kubernetes, and you have Linux workloads that are being orchestrated – whatever automation mechanism you have – Chef Puppet.
There are other ways to do it. So for instance, when you launch a process, typically a process is launched by a user. Who is the user that launched that application or that workload? That is something that you can derive as a way to get identity for who launched this application. And you can use that for policy. What is this workload running? Like for instance, is it running a Linux? Is it a Linux process? What libraries does it actually have? Any sort of container image vulnerability data – so for instance, you can scan the container image to see if there’s any vulnerability data – and you can use that to actually define policy. Because one of the things you want to do is – say, for instance you have a container, a frontend container, that has a number of CVEs. It has a critical vulnerability.
First you want to get visibility into that. So I have a frontend workload that has vulnerability data, and you want to get visibility to that. Or you want to define a policy. You can say, “Hey, if this vulnerability is not remediated in the next 30 days I want to deny communication. If there’s a vulnerability, I want to make sure all communication is logged to see if there’s a potential indicator of compromise.” I can also get data around where this application is launched. So for instance, in this example that I’m showing you here on the right side, it’s actually a capture – what we actually capture from applications. Where is this application launched? Which Amazon region? In this example I’m using an Amazon workload. Which AWS region is it launched in? Which availability zone? WhichIP address is it tied to?
All of this information, think of it as key value pairs that you can use to write policies. And the more information you have the more attributes you have that are relevant to actually defining these policies, the better off you are in defining these policies. So this is actually what we mean by cryptographic identity, and this identity in itself is signed, so nobody can spoof it. And we’ll talk about that later. So at Aporeto what do we do? We kind of think of the product in two ways. We solve two problems – cloud network security, which is distributed network security for east-west traffic segmentation. So this is instead of putting a firewall in your public cloud infrastructure you essentially have a very distributed security model.
And you can use this to augment cloud-specific security controls, like security groups, because security groups are hard to manage, and they have their own sets of limitations. They don’t work outside the cloud environment. So if you need a homogenous solution obviously security groups are not going to give you that homogeneity. Microservice security – so this is really more focused around turn-key segmentation for a Kubernetes environment. So if you have a Kubernetes cluster – if you’ve ever deployed a Kubernetes cluster you realize that to define network security policies they’re only relevant within the context of the cluster. As soon as you have multiple clusters or you have a hybrid environment to define segmentation policy becomes very difficult.
So that’s a problem we solve. And we also solve API-level access control, so you can do the same level of network – what we do for network security, we can do that at the API layer to ensure all communication at the API layer is authenticated and authorized. How do we do this? The toolkit is you have this concept of workload identity that defines your every workload. We use zero trust segmentation to authenticate and authorize all requests. We give visibility, and I’ll show you an example of how we get this visibility – so any application dependency maps across heterogeneous. And we solve encryption as well, so if you want to encrypt traffic going over a public infrastructure you don’t have to have some sort of an [IP-type] VPN to solve that problem.
You do it directly from the host. Any app-to-app communication is encrypted. We also do things like mutual TLS offload. So if it’s not just encryption at layer four, but you’re doing encryption at layer seven, we can solve that problem. And in fact, the layer seven encryption solves a number of problems. You don’t actually have to do things like TLS in your own application or any maintaining sort of PCI infrastructure in your application. So we take care of those problems.
Okay. So how does this solution work? The way it works is you have enforcement endpoint on the host, which can be a container. It can be a process. It can be a DaemonSet in a Kubernetes environment. It comes up, it registers with our staff service. The staff service is what we call the security orchestrator. It gives you observability identity. It’s the policy engine – the PKI logic built into it as well. So the Enforcer, when it comes up it has to register. It has to identify itself. And there’s multiple ways it can identity itself. In fact, we have some automated ways to do this in public cloud environments using identity documents that are available to us from the public cloud infrastructure.
So we can establish who to trust. So once we’ve done that there’s a certificate signing request, and that whole PKI kind of logic that goes through to ensure that the Enforcer has a route of trust to the centralized controller. Once that is done it – so we’ve given it some identity. Now the application comes up. When the application comes up, again, as I mentioned before, we’re able to introspect the OS or the Docker API or the Kubernetes API. And as part of that we give the application an identity. We get a policy that’s associated to that application identity, so we only get the policies we need. Again, the policies are highly distributed, so they’re enforced locally. And this is the interesting piece. When the application initiates a TCP connection – and what I’m showing you here is a simplified version, the SYN/SYN ACK/ACK.
As part of that process what we do is we actually embed the identity that we talked about – the cryptographic fingerprint – as part of the TCP handshake. And so any time an application tries to talk to something else that we’re protecting we are able to embed this fingerprint and ensure these two application components are able to talk to each other. So they identify each other first using the fingerprint. And then we enforce the policy using the policy that’s downloaded from the orchestrator. After that, once the three-way handshake is complete, we actually get out of the way. Because we don’t want to be in the data path the whole time. We want to only be in the data path for the three-way handshake. And then we actually get out of the way. I have to go back here for a second.
Okay. So the next thing I’m showing you here is – I’m kind of explaining to you how it works, so you realize it’s part of the three-way handshake. We’re able to exchange identity and then authenticate and authorize that communication. As part of that process, obviously, because we understand these two endpoints, these application endpoints, we give you very granular-level visibility. What I’m showing you here is an example of what we typically show in our security orchestrator. The communications between workflows – we give you visibility at the network layer. So what’s the network traffic? What port? What is the source and destination IP – things of that nature? Because we have API-level visibility as well we kind of give you, “Hey, this application tried to make a get request or a put request or the put request was denied,” that level of visibility as well, based on the policies that you’re defining.
And then also for every single communication we give you, “What policy was executed to actually enforce that policy?” If it was by default it’s a default denial. So if you see a red line it’s a denial policy. But if there’s a green line, and the flow was actually allowed, then we actually tell you which policy was enforced. One of the things that you’ll see in our platform is the first part to actually doing this is we have something called permissive mode. We allow customers to deploy the solution in permissive mode, so you can see the dependency maps. And then you can define – we can actually auto-suggest a policy as well. So that’s actually part of the solution, where you don’t have to necessarily know the policies to enforce. You put the solution in permissive mode. We give you the visibility across your applications, and then there’s a click of a button. There’s a wand that says, “Hey, would you like – these sanctioned communications – would you like to define a policy for this?” We auto-suggest a policy for you, and then you enforce those policies.
o let’s take an example – let’s take a case study – of a customer that actually went through this journey with Aporeto. And actually, we’ll talk about two customers. One is Informatica, which is a data analytics SaaS provider, and the other is Bart. If you live in the Bay area you know who Bart is. So the challenges they were facing was they were moving applications to the cloud. Specifically, in these cases they were moving it to AWS. And they were trying to retrofit a parameter security model just like we talked about earlier. And they ran into all those challenges. So they were trying to use security groups for segmentation, and security groups weren’t scaling.
It’s very error-prone because, again as we were talking about, workloads are ephemeral and security groups only apply within the context of AWS. So, again, all those sorts of things create challenges for customers when they go in and try to define security just utilizing security groups. And obviously, if there’s a constant change it’s also kind of error-prone. So what we typically see is, yes, security groups are there for very coarse level policy enforcement. But for very granular policy enforcement it becomes more and more difficult. Because we’re also wanting to get visibility at the application, spanning multiple cloud environments, so that was a very important requirement.
So as you can see on top, what the customer would have to do is essentially build VPN tunnels, put in firewalls, define these segmentation policies. Instead of that it was a much simpler infrastructure. Aporeto applies a distributed enforcement firewall across all of their hosts and use the distributed policy to enforce policies across multiple cloud regions and also get the visibility across all these environments. So that was kind of the journey the customer too.
As a result of these journeys – and I’m giving you some data point here – some really solid data points. What’s the savings? What’s the benefits to the business of deploying this sort of technology? So 70 percent reduction in DevOps OPEX because what you would need to do to actually try and deploy this using security groups of third-party firewalls and kind of automate that infrastructure – there’s quite a bit of work involved. And we kind of offer a very turnkey solution to solve those problems. So there’s a 70 percent reduction in DevOps OPEX, 50 percent reduction in network security OPEX, because again network security teams don’t have to go in and define rules. Every time an application is being deployed they don’t have to go manually define these rules or even build automation infrastructure to define those rules.
So there is quite a bit of reduction in even network security OPEX. CAPEX savings in East-West firewalls – typically when you deploy a firewall, there’s an upfront cost of CAPEX that you have to pay in buying that firewall. You may not use the entire capacity of that firewall, but you end up having to buy that firewall capacity up front. With a highly distributed east-west firewall segmentation solution like ours, it’s kind of a pay as you go model. So as you increase your workloads, as you increase the number of hosts, you actually just pay for the hosts that you’re deploying the distributed firewall instances on. Reduction in number of security rules configured reduces the risk. Again, because of this very abstract nature of defining policies, you’re not defining policies using IP addresses. You’re using abstract rules. There’s this application A trying to talk to application B. No matter where that application is that creates reduced number of rules across your infrastructure, even when applications replicate or get re-hosted, and that reduces risk.
So one quote that came from a large U.S. cable operator when we were working with them on a POC is – what we did for this customer in about five minutes to enforce policies would have taken them months to implement using traditional security tools and the current security operations they had. So there’s a huge reduction in time that’s required to define security policies. And the benefit to the business is obviously how fast you can go and deploy applications, especially in a world of microservices. You want to be able to go and deploy applications, make changes to environments on a daily basis, multiple times a day. And the existing practices of having to go define security policies becomes kind of a bottleneck.
So with that I’ll actually conclude the session. I have some very simple call to action. If you’d like to learn more about what Aporeto does we have some case studies, some technical documents that you can go through. If you’d like to try out the product we’d love to have you come in and register. Again, it’s a fast solution, so you can come in and register for an account and then just deploy the Enforcer technology on your virtual machine or your Kubernetes environment. It’s a very simple deployment procedure. To start with you can get visibility into the environment, and then you can define policies as well. We have some documentation to help you do that. So I will pause now to actually see if there are any questions that are coming up from the audience. So that was the end of the material. So if there’s any questions please feel free to ask them now, and then we’ll – yeah, so if there’s any questions, please feel free to put them in the chat box. Was everybody able to hear the presentation? Hopefully –
Okay. Well, if there are no questions then we can conclude the session. I’d like to thank everybody for their time to take time out of their day to actually join us for this presentation. I hope you found this helpful. Please do give us feedback. Let us know – if you want to learn more definitely reach out to us, and we’d definitely love to interact with you. So definitely reach out if you have any questions. Thank you so much for your time.
[End of recorded material 00:29:51]