[Start of recorded material 00:00:00]
Amir: Good morning everyone. This is Amir Sharif of Aporeto. This morning we have a webinar on Google application layer transport security and how Aporeto uses very similar principles to secure workloads and applications on any cloud and any infrastructure for containers and legacy workloads for our customer base. The presenter this morning is going to be Ariful Huq. Arif leads product management for Aporeto, and he will discuss Google ALTS and how those principles are reflected in Aporeto’s products that we then release to the market so our customers can have very strong security and easy operations on any infrastructure. So without any further ado, Arif, please take it away.
Arif: Thank you, Amir. Good morning everybody. So just to start off I’m going to give a quick idea of some of the initiatives within Google that they’ve talked about publicly. So we’re going to specifically talk about Google ALTS, which is the application layer transport security protocol that they have talked about in a white paper in very much detail. But this is not new to Google. They’ve actually been talking about the heavy investment in terms of security for their infrastructure and for their users quite a bit. It actually helps the community quite a bit. So one example is Google BeyondCorp initiative they talked about four years ago that was really focused on user/machine-to-app communications over a zero trust infrastructure driven by trusted identity. Again, I’m going to repeat trusted identity, because that’s going to be key to our presentation as well. So today what we’re going to talk about is Google ALTS. It’s an initiative within Google, specifically for app-to-app communication within their infrastructure.
So what is ALTS, and why are we talking about it? So ALTS is a protocol. You’ve probably heard of TLS, and TLS is very similar to ALTS, but think of ALTS as something specific within Google. They’ve developed it by themselves for their own requirements. But it has a lot of similar properties. But what it’s able to do is mutual authentication and encryption between all of Google’s internal services. So any communication for their apps that they’re protecting within their infrastructure is utilizing the ALTS technology. It relies on a trust model driven by trusted identity. Again, we’re going to use that word quite a bit, and I’ll tell you why. The identities are bound to workloads, and they’re not bound to specific server or host name. So why are we talking about it? As Amir highlighted, the ALTS trust model has a lot of common principles with Aporeto’s approach. And this is something that they have deployed across their massive infrastructure. So it is a good validation of what we’re doing here at Aporeto.
So there’s three fundamental principles that we’ll highlight – one that relates to transparency, which is when you do authentication encryption and all those sorts of things, the application should have no idea that that’s happening. Identity model – we’ll elaborate on that and then simplicity at scale. Obviously, anything that you implement has to be able to scale. And Google highlights this in their white paper.
So let’s dive right into it. The first concept is transparency. So security of communications between applications must be transparent to developers. We don’t want to burden developers with encryption technologies. And there’s a number of reasons why we don’t want to do that. So one of the examples that I highlighted here is, yes, if you have a legacy application, and you need to integrate TLS, for instance, because you need to meet some sort of compliance requirements. Say you’ve got some sort of PCI application, or you’re handling patient-sensitive data. And all of that data needs to be encrypted in flight. It’s spanning untrusted networks. That data now needs to be encrypted, and you now need to include TLS into your application somehow.
The better approach to do this is to offload the TLS from the application. So there’s no changes to an existing app. Your developers don’t have to go in and change an existing app to incorporate this capability. This allows a few things – easier management for developers. Take an example here. You’ve probably heard of [Hartley]. It was a CVE associated to openSSL – technology that’s used for TLS. Now if you want to go patch this specific CVE you have to go in and essentially make a change to all your software and redeploy that software. It is quite a bit of work.
So we certainly want developers to focus on their logic for the business application they’re developing. And we want to offload the encryption, authentication and authorization capabilities away from that application. Performance is a big issue as well. You kind of want to offload that to an external piece of software that can take care of it in a much more efficient fashion. So this is something that was very important to Google, obviously. Because any application that they’re developing they want to make sure it’s all encrypted, and they want to offload that from their developers. Aporeto does this today transparently for all in flight data, and we use mutual TLS. We use ECBSA keys, so it’s cutting edge in encryption technology.
So the second concept is around identity model. So first I want to kind of set the stage on why we are talking about identity. So here are some of the things that if you have developed an application or if you’re deploying an application today in a cloud or you have some experience doing this, you’re probably going to come across these problems. So any time you go ahead and deploy an application in a cloud environment, most likely you’re going to have a virtual cloud environment where you’re using a private address space. And you’re mostly likely going to do things like NAT, network address translation. So any traffic that’s originating from your virtual private space is going to get NAT’d – very common thing that happens. You’re probably going to do things like proxies and load balancers, right? This is even more relevant in the case of cloud-native applications, because in cloud-native applications you have a lot more components. And you want to build some redundancy, so you have a number of these components that you expose through an ALB, and application load balancer or some sort of load balancer technology that you have.
So just right there you have a problem here. So you’ve got private address space that’s being masked by doing that gateway. You’ve got load balancers that are masking the actual IP address for those applications. Today IP is being used as an identity, but it’s being masked by these technologies, so it creates a problem. And we’re going to show you more details why that’s a problem.
Then you have workload replication. So if you’ve got some sort of elastic application, you’re using some sort of autoscaling group for instance, because your front-end application is in the cloud, and you have heavy traffic and you need to increase your front-end. So all of a sudden you went from five containers to, say, 15 containers. That means you have 15 new IPs that just came in, and these IPs are being assigned randomly. And you have no idea what these are. So if you’ve written a rule based on IP addresses, if you’ve written some sort of policy to restrict communication based on IP addresses, that becomes a challenge. What customers end up doing in these types of scenarios is they say, “Hey, let me just allow all IPs or all sources within this specific range.” So the workaround tends to be, “Let me create a coarser policy,” which leaves room for attack.
And then third is around workload rescheduling. So I’ve got some sort of workload that may come up during part of that day. Perhaps you’re doing some sort of database replication, so something gets scheduled and then it goes away later. And again, when this happens, if you’re using some sort of scheduler, there’s no guarantee as far as this workload is going to come up on this specific host. You’re mapping an IP to a specific host. There’s no guarantee that that workload will come back up with the same IP on that same host. So that becomes a challenge.
So to highlight – just to kind of summarize – traditional models of using IP addresses for access control/policy enforcement and application visibility is extremely difficult because IP is not persistent, especially in dynamic environments like cloud and in cloud-native applications. And to share with you a very interesting talk that I heard at Amazon Web Services Reinvent last year, Netflix went through a tremendous amount of work to kind of correlate information that they had within their network just to figure out identity for their apps in the AWS environment. It was that important to them. They needed to know, “What was the identity of a specific container or microservice that was coming up?”
And what I’m showing you guys is something called Sonar. It is an application that they wrote that would correlate data between quad watch events, VPC flow logs, AWS API, Netflix API, DNS calling. There’s a tremendous amount of work that they actually had to do to figure out what applications were being spun up and what were the source and destination addresses for these applications – to kind of make sense of the communication that was happening. Because they wanted to get visibility. They wanted to understand if there was any attack, any threat vector. They wanted to make sure that they wrote the right policies for those applications. So it’s a very difficult problem to solve. But this is something that Google, utilizing the identity-based model actually is solving. And I’m going to highlight to you how we’re actually do it as well.
So a better approach to solve identity is to really look at – when an application comes up you figure out, “Where is this application coming up in?” Is it coming up in my private cloud environment? Is it coming up in my public cloud environment? And there’s some metadata that you can extract that gives you this type of information. The diagram here – I’ll actually explain to you how we’re doing this metadata. So you’re going to get metadata, and the metadata is going to give you information around the application. It’s going to even tell you things like, “Hey, is this running in Nginx boxes? Is this a database?” So you can even get that type of information. So what is it running? And you can even start to get things like behavior. You can figure out, “Hey, what types of system calls is this application making at the host there?”
I can start to profile and figure out, “Hey, does this application meet a specific profile, based on the system calls it’s making?” So I can derive information from there. So I’m using context in a number of those areas. Where are these applications coming? What is it running? What metadata does it have? Where was it built? You can look at things like a specific image ID. When was it created? If I have integration back into my CI/CD pipeline I can actually figure out where this image was created and validate that information. With all of this information you create a very valuable trust profiles. And if you look at the ALTS paper, this is sort of what they’re doing. Every time that Google spins up an application in their environment that application is attested. So it actually goes through an attestation process. And after that application process, it gets an identity based on metadata and a bunch of other information that Google has within its network.
This is a much more automated and a much more reliable way to figure out, “What is this application?” and tie an identity to it. And not only that, you create a trusted identity by cryptographically signing this identity. And we’re going to talk about that. We use a concept with PCI, public infrastructure, to actually sign this trusted identity. So a few important aspects here – trusted identity that’s established to workload attestation. When this workload comes up you actually attest, “Should this workload come up on this host?” And you get this metadata extraction. A few good examples here – by utilizing things like AWS identity document, and I’m going to show you that in this diagram here.
And there’s some standards coming up for this called SPIFEE. SPIFEE allows you to do this as an agnostic technology over any cloud environment. It allows you to attest and getting an identity for a workload across any environment – whether it’s public cloud or a private cloud environment. But let’s look at an AWS identity document, and this is an example of us spinning up an application in AWS. And what I’ve highlighted here in red – it gives you an idea of – I can figure out, “What is the AMI?” This is an Amazon Machine Image. What is the instance ID it comes up in? It tells me things like, “What application is it running?” Which region is it running in? So it’s giving me very rich data that it can start figuring out, “What is this application?” and then start to write policies for these applications. So that’s what we mean by identity and why that’s important is because we’re no longer relying on IP addresses. We’re relying on context to figure out identity.
So any sort of solution that you look at from a security perspective, it certainly has to scale. And when you look at Google’s infrastructure, obviously, it’s massive. So any technology that they end up adopting has to scale. So we talked a lot about certificates and how we build trusted identities, things of that nature. That means you have to have key distribution. What I mean by that is when you assign an ID to a workload or to a specific application, you’re going to have to build some sort of identity, and you do that through some sort of certificate authority using PKI. Now you’re introducing, actually in some respects, more elements here.
You need to be able to automate these sorts of things. Even things like mutual TLS, if you’re using keys from mutual TLS as certificates, and you’re generating those keys, somebody has to manage those things. It has to be very scalable. So if you look at the ALTS paper, all of that is something that’s automated in Google’s environment. The developer does not have to worry about any sort of e-management or certificate management, which is very important. Not managing PTI infrastructure and having you do things like certificate distribution, rotation and revocation is extremely important. And you automate this at scale. It makes things like this much, much simpler. At Aporeto we handle all of this. We make use of all these technologies. And all of this is actually handled for you on a per-tenant basis under the covers.
And the last concept I want to explain is around policy propagation. Any time you have a massively distributed system, and you’re doing things like policy enforcement, all of it actually has to be very localized. Any decision that you’re making to actually allow a specific communication – that decision needs to be very distributed and localized. If you start to think about the way customers have been doing these sorts of policy enforcement using IP tables or IP-based policy, it’s actually very hard to do this in a distributed fashion.
An example is what I’ve highlighted here. You’ve got an application – App 1 – and then you’ve got an App 2. App 1 needs to communicate with App 2, and App 2 is using something for auto-scaling. It’s automatically pulling the number in. It’s replicating. As soon as you replicate you want to be able to communicate with these other instances. So you’re balancing the traffic. But if you use an IP-based policy now you need to go in and change the rules on every single one of your hosts to tell that host that, “Hey, there’s a new instance that’s up, and you need to be able to allow that traffic.”
That means the system needs to converge, and you need to propagate this information. That creates a challenge. Now if you do this using identity, and you’re able to actually say, “Hey, any time App 1 wants to talk to App 2, allow that communication.” You don’t actually run into these kinds of problems. So it’s very fundamental that enforcement always happens in a very distributed fashion. And if you look at the ALTS paper, that’s exactly what they’re doing. All of the enforcement rules are actually very heavily localized in all of Google’s infrastructure. And that’s exactly how Aporeto operates.
So I’ve talked about ALTS, the fundamentals on ALTS and how they’re actually very similar to what we’re doing in Aporeto and why those decisions were made. So let me just give you a quick idea of Aporeto, what we’re doing at Aporeto, and then I’ll kind of show you how you can try it out. And then we’ll go into Q&A. So Aporeto, as a solution, we offer it as a staff service. And essentially, everything that we’ve talked about is something that you can consume as a staff service. So the policy engine, the statistics and logs that’s giving you visibility, the identity management for every single one of your workloads for communications between those workloads – all those things are being managed by us. Certificate authorities to make sure our key distribution and certificate management – all of those things are being taken care of by us. Visualization and monitoring – so we give you visibility across all your application endpoints to our software.
Just putting us in as a pod in a Kubernetes node or as a container in a Docker host or as a Linux process in a bare metal host is all that’s required for you to start making use of this technology. And on top of that, we’re adding things like image scanners to start to give you vulnerability analysis. What is this image that just spun up? Does it actually have vulnerability? If it does, let me alert you on those certain things. Integration into themes and sort of Splunk – so start to push this alerting data into your existing Splunk database so you can start getting that information and getting more context. So that’s what Aporeto is offering. Very, very simple – you have an Aporeto service. You sign up. It’s a staff service, and then you’ve got the Enforcer, which is a pod or container or process.
So with that I’m going to conclude the presentation, and we’re going to head into Q&A. But before that, you can try this out today. You can create a free account with us. Go into this link here. There’s some instructions in there that you can follow. We’d love for us to reach out to us if you have questions. Feel free to reach out – email@example.com – and follow us on Twitter. So that’s it. Amir, if you want to take it away for Q&A.
Amir: Thank you, Arif, for that presentation, and I’m going to unmute everybody. And feel free to raise your hands and ask Arif any questions you might have. Or you can text those questions to me directly. Arif, I have a question that has come in. It’s asking about the question of identity. The question is, “How rich is Aporeto’s identity, and from where do you extract the data?”
Arif: That’s a good question. So we just go back a couple of slides, the context is actually very rich. As I was highlighting, there’s a number of ways for us to get this information – especially in cloud-native applications like containers and microservices where you’re generating these images using automated processes. So you can get things like image IDs. You can figure out, “What does this image actually contain?” Is it running Nginx, Mongo? Where did this image come up? If you’re running it in a public cloud environment we’re able to figure those things out. So there’s a lot of very rich context you can get – a number of ways to get this information. And on top of that, you can do a behavior model. You can figure out what kind of calls and how this application is interacting with the kernel to figure out what is this application – what actually it is. So yeah, those are a number of ways we can do it today.
Amir: And just for clarity’s perspective, can you relate the identity model directly to security and the concepts that are pushed out by Google ALTS?
Arif: Absolutely. So once you actually have this rich identity, for you to be able to create a policy now becomes very, very easy. So you’ve identified a specific application, and for you to say, “Hey, I need to allow specific communication from this specific application with identity X to another application with identity Y.” That becomes very, very simple. And with ALTS that is exactly what they’re doing. So every time an application comes up in Google’s environment it’s attested. They figure out what that application is, what that process is, and they figure out, “Who should it be allowed to talk to?” And they make sure that when they establish the ALTS connection that those are connections that are allowed. It’s mutually authenticated by those two endpoints. So again, no reliance on host IP, no reliance on anything that is not persistent. You’re relying on something that is tied to that application workload.
Amir: This isn’t a question, but it’s an observation. A while ago, Google came out with an article or document named BeyondCorp where they explained that all of their systems are effectively on the internet. And as far as we know, there haven’t been any significant security breaches for Google – certainly nothing on the scale of Equifax or Target. Do you think ALTS is playing an important role in this – in protecting their internal applications, despite everything being out public-facing?
Arif: Actually, I think that’s the case. In fact, I think Google has learned that the traditional models of perimeter security doesn’t really work. And so they actually started this journey with BeyondCorp where they realized that for workers that are within Google’s office, or are working from anywhere in the world or from a coffee shop, they should be able to identify that specific individual to the identity of that user through the machine that they’re coming in through and then allowing that user to access an application that they’re allowed to access.
So they took that concept and implemented it for app-to-app communication, so you can think of user-to-app and then app-to-app. So now with app-to-app, certainly the fact that everything is attested, and everything is driven through policy and identity that’s been trusted, it really solves some of the problems that we saw at Equifax where you have a user coming into a specific host and then doing lateral attacks into the rest of the network. That’s something you can easily avoid with this type of architecture, because apps can only talk to any other app if they’re allowed to. So lateral attacks and that segmentation becomes very, very granular.
Amir: Very well, thank you. We’re getting near the end of time, so there’s room for one or two questions. One of the questions that’s come in is, “Application identity appears to be a very dynamic and morphable entity. How does Aporeto work with dynamic identity in order to ensure consistent security for all applications in an enterprise?”
Arif: So the identity of the application is – in terms of when the application comes up and what is that application – that is sort of persistent, right? And what we’re doing is we’re actually signing the trust of that application. So we’re saying, “This is a trusted identity, and we’re going to sign it with a certificate,” to make sure that there’s no – you can’t change that identity once that application has come up. So even in a dynamic environment where you have applications popping up all the time, you’re able to make that – get that rich context, figure out what that application is, sign it, make sure that nobody else can change it. I can’t say that I pretend to be an Nginx process, and I pretend to try and get some sort of policy that allows me to communicate with something else. That’s not going to work because not only are you deriving context, but you’re actually establishing a root of trust for that context.
Amir: Very well. And onto the last question, which is, “How does Aporeto provide security outside the application in an open environment?” So I think this question goes to the technical implementation details of the security provided between application components. Could you elaborate on that?
Arif: So the question is related to Aporeto communicating with other applications being protected by Aporeto or sort of an external service that’s not protected?
Amir: The way I read it is, “How does Aporeto provide the security function for the application components?” So it’s the same application.
Arif: Got it. So the way Aporeto does it is – we talked a lot about that identity. So what happens is when this application component tries to establish some sort of connectivity with another component that’s being protected by Aporeto, what we do is we’re able to inject some information into that communication’s – that transport communication and TCP – and we’re able to basically verify this information, this trusted information and ensure that I have a policy that allows this communication to actually happen.
So not only am I authenticating – so I’m figuring out, “Hey, should this application talk to another application?” I’m authorizing that as well through a policy. And all of that is actually done in line using context that we’re adding into the TCP packet, which is the very interesting thing about our solution, the fact that we’re doing it in line allows us to do this in a very, very distributed fashion. And it also gives you some rich data for visualization. Just using the TCP data we’re able to figure out, “Hey, what is this application?” I’m able to give it a label and figure out what else it’s communicating with.
Amir: And I know we’re short on time, but you also alluded to the point that Aporeto can secure applications that are under its security control to external resources. How do we do that?
Arif: Good question. So what we do in our system is we’re actually able to define an external service. We’re able to say, “Hey, this is an external managed database,” perhaps, or some sort of external API that you want to reach out to. And we’re able to define that as an external service within our system, add a label to it, and then you can actually get – because now you’ve defined some context for it. Now every time you write a policy you can call that label. You can say, “If this app wants to talk to an external database label Y, then allow that communication.”
Another very interesting thing that we’ve done is for hosted services within AWS, for instance, we’re actually able to discover all your hosted services. So for instance, you’re using an RDS database or you’re using a load balancer, or you’re using some sort of SNS service. We’re able to discover those things, and we’re able to actually tell you that, “Hey, you have these external services, managed services, within your environment.” And you can say, “Should I allow communication between my Aporeto protected services and these managed services offered by the cloud provider?”
Amir: Thank you, Arif. It’s precisely 30 minutes after we started, and I appreciate your time and your explaining what Google ALTS is to our audience and how Aporeto works. For everyone listening to this webinar, please visit our website, Aporeto.com to learn more about what we do, cruise our blogs, and also go to Twitter. @Aporeto is our Twitter handle, and there are frequent announcements, including the posting of this webinar that will be coming up. And we’ll have a repeat a week from now. Thanks everyone, and we will talk to you shortly at our next webinar. Thanks so much. Bye.
Arif: Thank you, bye.
[End of recorded material 00:31:06]