Aporeto Technology Overview with Dimitri Stiliadis

thanks everybody for joining my name is Dmitry status I'm the co-founder and CTO for Baretto we're about a three year old company the first thing that I will start is with a disclaimer Tom told me that I cannot put confidential on any of our slides and I told him is actually impossible so just so that you know the name of pareto comes from the Greek word appetito that actually means confidential so every single one of our slides has confidential written on it because it has the name of our company there so that's a the or is enough mist of the name if anybody was wondering so where did a Pareto start and in the other Kapur endo started after want a lot of years of personal pain I have been in the networking and network security years for more than 20 years right now and over the years I solve this pain of trying to secure applications networks and so on and every time we would delegate the security to the network they would get another network tree but we would do in order to create a better security environment and then we move to the cloud we move to something like this where applications are spread across regions availability zones across cloud providers you have what I call the working infrastructure over there that means the interface with these applications partner networks external services and so on and then we get micro services and containers and functions on top of this and the number of workloads has exploded the frequency that they get activated this Explorer has increased dramatically and we try to secure this thing and when we try to secure this thing we the first inclination was to take the things that we knew that we were doing in a classic enterprise environment and try to map them so we started doing firewalls we moved Fargo's made them virtual appliances we did VPN tunnels we did network virtualization VX LANs whatever by the way kill pretty I was doing that for several years and then somehow we need to orchestrate all these things in order to get a security solution out of this the probability of an error as things are changing rapidly as things are moving rapidly is extremely high and the complexity the operator operational complexity of managing such a network infrastructure together with all the security appliances around it is even higher so when we looked at this picture we took a step back and said what is the problem we are really trying to solve the problem we are really trying to solve this a security problem it's not real a network problem so let's solve the security problem where it belongs let's solve the security problem close to the applications and let's use techniques that are validated in the in the security world for a lot of years in order to achieve that so that's what I'm going to talk about now there are classic fallacies that in this type of architecture and the way that the industry has approached it in the past for example host-based firewalls right so several people recognized similar problems they went to the approach of host-based firewalls and said host-based firewalls I can scale them with applications I can move all over the place so I can use them for example as a security tool and then you get this problem right considered just two applications application one and application two and that we both of them are elastically scaled applications right so they consist of multiple instances if you are you try to solve a security problem between them based on a host based firewall or any technique like that you end up in reality with n square rules you need to cope with a rule from F for every single one of them this one can access this one this one can access this one and so on and so on you scale up the application with a new instance you end up adding n more rules for every new instance you scale up so as u s-- try to scale up it becomes impossible to follow this Boston and go program firewalls or program ACL rules so program whatever to deal with this issue but this is not just the only issue let's take another classic example nobody's running applications without load balancers right so you have an application you have a load balancer in the middle and you have the target on the other side you go to the cloud the application is in alb right it's an elastic load balancer out of AWS or out of Google or whatever so how do you do security to do that well you can say I'm going to put nacl to allow this entity to talk to the elbe I'm going to put another HCl to allow the Elbe to talk to the destination IP but what happens when somebody else comes to the Elbe right how do I protect the Elbe now and not only that as it turns out Amazon and most of the cloud providers are constantly changing the IP addresses of the lbs right so every hour every whatever they will sense them they will scale them they tell you use the fqdn don't use de lb classic problems that you have to deal with in every deployment now there is another what I call in lusion of security it's the Hulk idea of the hybrid cloud and undressing hybrid cloud security so I have my applications in the cloud and I have a private data center and the rule of thumb has been so far the way I'm gonna secure this environment is I'm gonna do a VPN extension or a Direct Connect from my V PC directly into my data center and therefore everybody here will think that this is an extension of my data center right we have seen this picture so many times what is the problem with this picture the problem with this picture is that the blast radius or if you go on the perimeter over here is not your V PC it's not your network the perimeter over here is actually the account credentials so anybody that actually manages to get the account credentials for this entity over here can come and first of all modify VMs modify applications they can actually come and create a new application in this in this environment over here and what happens then the application gets DirectAccess in your own data center so the idea that I'm gonna secure a hybrid cloud by opening a tunnel or by between my my AWS or my Google cloud and my private data center discuss fundamental flows because your security parameter is no more than Network your security parameter is European gates on credentials a user loses their laptop their affiliation credentials are gone right you go to slash dot AWS credentials you get them you are you are free to do whatever you want to do now if you think about it like right now if we take a step back though and see how the all the main cloud providers are actually implementing security they don't ask you to go to special subnet to convey WS API in order to activate the VM they don't ask you to give your IP address or your office address to go to Google and activate the VM what they have is they have an identity and access management domain pretty much everything is managed through identity and access management at the API layer and this allows them to scale their security to this their security model to cover both users and machines and what this allows them to do actually is to they use actually the same technique both for accessing the clouds by themselves as well for cloud in their actions if you want between them so the question is if this is the way the cloud is doing security why are your application still using traditional networking techniques to do security and that's what we are gonna come and talk about here essentially what operator is we completely abstract the underlying infrastructure we don't really care what the line the line infrastructure is our view of the world is that your applications are moving anywhere they can be placed in the cloud they can be placed in private data centers and so on and the whole concept of operator is to provide essentially an identity and access management layer for your applications not for applications accessing the cloud but for your applications so what is this Identity and Access Management layer this essentially says that I'm gonna introduce end-to-end of indication of realization and encryption everywhere I'm going to introduce everywhere apk our infrastructure to manage certificates to manage keys to manage identities I'm gonna completely I don't care whether my traffic goes one network ten networks whether it goes of net over network address translations whether it goes over load balancers or anything everything is end to end and my policy is completely portable so essentially in one sentence what I'm going to talk about is essentially about an identity and access management layer for your applications that becomes actually the center of security and you will see how this layer can be used not only for application to application security as well it can be used for user to application security it can be used for user access control there is a whole set of use cases we're going to talk about today okay so as I said the and this is where the provocative statement start right so there is the biggest fallacy of network security is that network visibility implies authorization the fact that two entities can exchange packets is translated by most of the world we have done in security right now as the ability to exchange information the fact that King they can exchange packets doesn't mean they can exchange information we need to decouple the two and that has been one of the fundamental fallacies we are trying to change over here so what I'm going to talk about now is okay so we want to create these Identity and Access Management layer what are the fundamental principles behind our design services and more important as we go down the road what are the components we need to implement that how can we operationalize something like that so as I said the threat model we assume is the network is insecure by default whether it's your enterprise network whether it's your cloud it doesn't matter somebody will find their way inside your network we also don't make any assumptions that you own the network because when you live in the cloud you don't own the network so it doesn't make any sense to do over the anything over there the network primitives as Jason said rll really irrelevant IP addresses port numbers are a famila ephemeral they have no context right any action must be explicitly authorized any interaction between workloads any interaction between users and workloads must go through an identity and access management process and the team must be explicitly authorized and the question is how do you manage that and that will be a big part of our question how do you manage that the authorization effort if you go on they need need it for this authorization and it's not easy right we recognize that it's not easy if you actually see I saw two announcements this week the one who was from Google+ the now-defunct Google+ where they lost a lot of data because why because of an authorization error Facebook just today again announced that they lost of a lot of data why again because of an authorization error so getting into a model of operationalizing authorization yes it's not easy so you need the central mechanism using the common mechanism to send it to to manage authorization the other thing is now okay we need to authorize everything but authorization need to be context and environment aware so let's assume I have an application if I start this application in this V PC the Google in the in AWS or Google that is handling production workloads it will have a completely different security posture requirement than if I started to make you a environment or if I start an application that the suddenly misbehaving it's doing things that I don't expect let's say it needs to get a completely different offer ization profile rather than it is an application that is pretty static so the authorization needs to have context like where is it running when did it did it did it start by who busy try by whom was it started what is it running what is it currently doing and so on the other principle that we have in all this design is the separation of concerns between the security functions and the application logic so and exactly that goes back to the two examples that I saw about Facebook and Google that if you put all your authorization logic inside your application you tied to your business logic the risk that you are taking is that some developer makes a mistake or somebody makes a mistake or somebody does the wrong implementation or whatever the goal here is separate your authorization your identity functions your cryptographic functions separate them out of your application logic and what this gives you the ability to do is first of all manage them centrally all together like an entity but more importantly they have their own life cycle completely orthogonal to the life lifecycle of your application meaning absolutely even this software even the software that is protecting and I have abilities but you should be able to upgrade this software without affecting the applications and you should be able to upgrade the applications without upgrading the software right this is the separation of concerns type of logic so putting it all together where these letters is essentially to these architectures that I explained earlier that essentially what we do in a Pareto is we go to every workload no matter whether it's a container whether it's a little process whether it's a function whether it's a horse and we automatically assign an identity with this workload and this is a cryptographic identity that I will talk a little a lot about it later but it is a multi-dimensional identity that allows us to capture not only you know and fqdn name for example but an fqdn name and all the characteristics of the work that is running based on this identity then we insert pretty much transparent end-to-end authorisation everywhere and the same to entus indication and authorization everywhere is managed through a centralized policy and visa and visibility system right so the whole idea here is no matter whether you have a new application an old application we have installations working back with Red Hat 5 doing the exact same thing as well as with the latest and greatest Cardinals and with docker and functions and whatever right so no matter what you workload without touching any code of the workload we insert the sensory this transparent authorisation everywhere and we change the security model from being something that is network based to being essentially an identity and access management security model good so far if you guys have any questions or any disagreements please interrupt more yes well I just like to point out that in the the threat is much different especially an open source software because nothing is signed anymore right so there is there is a different part of thread that says a whether for example my packages of my library dependencies yeah your honor the correct one right right so you will see in as part of this presentation how through doing will variability scanning or cold scanning the version of the library who are using the version of the packet we are using is just another attribute in this multi-dimensional identity right the fact I'm running this application with these vulnerable libraries is an attribute of the identity therefore my policy can be if anybody has venerable library well you cannot do anything it becomes as simple as that even if somebody surreptitiously taken over a library like an NPM library well I mean to a certain extent that the vulnerability is known right I mean obviously if it is if it is not known we are not going to be able to to detect it but we will be able to detect some behavioral aspects that I'm going to talk a little bit later so in order to build this system in order to build essentially an identity and access management system what do you need so we start with the idea that there is an infrastructure and you have hosts you have containers you have processes you have functions potentially and you have users and the first thing we do is we create a uniform identity layer and this uniform identity layer normalizes and create identities creates cryptographic identities for every single one of these entities so the every host will get a unique identity every container every process every function every user will have a unique identity this identities are normalized if you want in the same format they're normalized actually in a normal format so once we have the identity layer we have a policy layer and the policy layer manages authorization any authorization in between these functions in between hosts and processes containers and functions whatever users and and workloads write the policy layer manages the authorization in between all the actors if you want in a centralized at least logically centralized way where you can analyze and see actually what is happening and then somehow okay we have an identifier a policy we need to enforce it and we're in the enforcement is where we fork out if you want and we have different enforcement runtimes depending on if you are a horse or if you are a function or if you are a user you're gonna see several different runtimes that allows us to enforce this end-to-end authorization across all these different environments and we keep the same security level everywhere now when we do that last but not least there is a monitoring element there is a monitoring and recommendation element that we'll talk about where we always monitor how the identities are created what are they in their identities what is in the policy layer what is happening in the runtime and this becomes a feedback loop that allows you to automatically create policies and automatically adopt policies right so there is a there is a feedback loop in this equation ok so when you started out you started out rightfully and I think we're all cheering in the background looked that way it from Twitter to talking about the complexity of firewall rules now with that elastic scaling and everything it doesn't really work but at least with firewall rules are only dealing with hosts for the most part now you had a containers many-to-one processes many the one functions embedding the one how are you handling scaling through all of us right so a very very good question actually and that's where all the IP based things fall apart you will see when we go to the detail essentially what is happening is when a host comes up or when a container comes up or when a function comes up we need to give it an identity this is a single API call that gives it an identity once we give it an identity there is no other interaction that is happening with the system on top in order to figure out what else to happen the enforcement is distributed to every host every container every process and so on actually scales with a infrastructure ok but we'll talk about that actually in in detail so what we do now with this authorization and because applications have different needs right not everything is an HTTP call people use all protocols they use various protocols what we allow you to do essentially is we allow we enable our users to Bofur ization at layer 3 at layer 4 into layer 7 I'll explain how it's done on every layer of the stack but this works across everybody other than functions because especially in functions there is nothing that you can potentially do at layer 3 anyway so the bottom line here is if you want to say that this process is authorized to open a TCP connection in this process you can do it at layer 3 if you want to say that this process is authorized to go over five load balancers to this process you can do it on layer 4 if you want to do it at layer 7 you are essentially saying this process can do this API call to this other process but it cannot do that other API call right so the granularity as will go up the stack becomes finer and finer and the opportunity for differentiation between what your applications do becomes finer and finer you set a specific API calls almost like a Web Application Firewall when you're looking at it it's essentially an API proxy gateway so let me go and talk first about the identity layer as I said the identity ladies at the core and it is significantly different and everything done a lot of the other things that I have seen around what is an identity for us right so what we do actually is we the moment the process comes up we go out and find two held metadata where is this process activated service account identities what service accounts have I given to this VM or this cost and so on orchestration metadata from kubernetes from Essos from other orchestration tools vulnerability data if this process if this container is being scammed currently what are the vulnerability data that we can found out of this process host information data what operating system is running what kernel isn't running does it have a CPU that has the the XYZ vulnerability what are the software layers of the stack all this information is combined with a set of dynamic metadata what do we mean by dynamic metadata I have an application that is running for a while and it's now doing but network accesses this is an indication of compromised potentially right so application behavior and system behavior become metadata that enhance this fingerprint threat field from outside become additional metadata that enhance these fingerprints so we combine all this data today together in an application fingerprint this becomes a JSON document we cryptographically signed a JSON document and any action then in the system is authorized based on the any of this data that you can choose to use you don't need to use all of them you can just say everything from AWS to disappear automatically encrypt or you can just use all of them is that a question okay so this is the concept of their identity so essentially for those familiar with OAuth and JSON web tokens this identity is essentially all this data become claims in a JSON web token that's what happens underneath the hood now as I said how does this work well there is the operator enforcer that is running on the servers or the container host or other execution environments with enforcer continuously monitors for new entities that are coming up and when it discovers new entities that are coming up it goes and scans the environment for all the available metadata that can be found and talks with various other tools if in case it's needed and based on that it creates this unique identity or this unique fingerprint for every application and then cryptographically signs it you're just gathering that like I have a hash of others no element we actually have a JSON document with every single one of these elements in there okay and then you sign it and we sign the whole JSON document okay that's cool you put a digital signature at the bottom of the correct JSON correct mica and do Java Script parsers can they read that they don't even go there right so this JSON document is essentially an OAuth token if you want is this JSON web token right so all the data go as claims as data claims on this document and then we'll reuse a whole PKI infrastructure that signs these documents and then they are encoded as base64 and they make it into the data path and we'll see how they make it into the data path depending on the layer yeah okay okay that's pretty clever then so in other words you you're leveraging other strengths of OAuth yes and just adding on the signature for that I mean the the tokens that we create the irrespective of the layer they are all all worth tokens at the end of the day now if that JSON document is modified in transit it will it fail to run yes Google automatically fail okay because of the integrity of the document oh and what protection mechanisms do you have in place to protect the enforcer and any of the other service components right so a very good question then for sure and we'll go into the details runs is a Linux process or is a docker container itself one of the main mechanisms is nobody can talk to them for certain it only talks outside and in addition to that we have mechanisms with restarts and monitors and so on that if for some reason the enforcer goes down or somebody kills it we automatically get a notification that is enforce it is dead therefore something bad is happening over there go go take a look at it well I'm thinking protection Mac hashes and certificates and all those are all tied so there so the in addition shield yeah so as we go into the bootstrap we'll talk about it more there's a whole bootstrap process in order to make the whole signing process to work there's a whole bootstrap process that is needed there is no private key ever stored in any file system private keys are always in memory and there is actually no private key ever transmitted over the network eki yeah so so we'll go over the bootstrapping process to make that as strong as possible so how are you dealing with the processor vulnerabilities that can read the memory good question I I cannot solve work are waiting the vendors okay however one of the things that we did is part of the metadata of a process on what we call in processing unit running somewhere is going to be whether the processor has the vulnerability so the other side can choose to trust it or not trust it okay okay thank you now and then essentially what happens is that's the OAuth token that's an example of an OAuth token and I was talking about this we actually get this application metadata and on the same way we can actually normalize things from TLS certificates and user identities and I will go and explain user identities as well we take everything and normalize it to a single operator identity that is as a root of trust if you want originating in the operator system and then this is going to be used for authorization across the board okay so you understand now that identities are just JSON documents with attributes so what is policy so policy is nothing more than an equation or a logical expression if you want across these attributes of the of the document so what do I mean by that a policy has a subject a verb and an object it's like an English language the subject says if you hit cloud equals disappea and pop equals payroll or vulnerability equals whatever and you are trying to connect to an object and that it's right now it's Monday morning and it has a low vulnerability then allow the action or encrypt the action or do whatever right so the whole idea is that a policy is essentially a statement of your right against any of the subjects and objects and it's a kind of understandable if you want in in an English language representation are you using a specific policy writing language no action you can program our system through through essentially yeah meladze so files and then these subjects objects or whatever are just fields on the file there is no although we would like to some point to go at some point of our lives to go there there is no natural language type to write it however there is a second important part of the of the policy that the system has been designed for enterprise environments and in enterprise environments the second issue you have to deal with and it's a big part of our policy system is actually who is the actor that he's gonna write the policy who is there who is there with the person of who is the organization right the actor that is going to update the policy what can the security team see what can the developer say how can we delegate control right a whole part of this effort here is to delegate control of policy writing down to the developers because everybody wants a secure application so they can write the policy however maintain controls if you want at the operations of security to think to make sure the policy is actually right so the whole system is based on the idea of the namespace header here so think that I have an enterprise at me then the enterprise can have underneath multiple namespaces / broad / qà useless whatever right so this is a sub namespace of the main namespace and then within the prod namespace you can have project one project - project 3 right so you get the hierarchy of namespaces and then you get for example the security department or the security organization they have full access at the top namespace and then security can introduce rules at the top namespace that they will start propagating down into the hierarchy if you want they hit the tricky energy of the namespaces therefore for example if security says I don't want any workload with these characteristics to ever talk into the internet right or whatever so they put the rule up here they propagate the rule it doesn't matter now if any other policy comes into the sub namespaces it will be overruled by the top rule of security however security the top owner of the namespace can delegate control for the for the sub namespace to another entity because yeah I know that nobody with is vulnerability stacks is the Internet but I don't really care how your applications are talking to each other or what is authorized here so it delegates control to operations and then operations can put their own policy and then operations can delegate control to the development team and then the development team can add their own policy and in reality when your workload leaves down here in the style name space it gets the combination of this policies prioritized based on who has actually provides these policies right so essentially the model allows you to create this delegation of authority model that will map to any organizational structure okay so that is the the policy model how do we enforce all these things as I said the goal here is to provide the same uniform Identity and Access Management layer irrespective of the type of workload or user so how do we enforce this there are several Western Force it if you have a Linux VM you can start the enforcer as a system this service in the Linux VM right it's an agent and it has by the way then forces do not touch the Linux kernel they have no kernel modules they don't do anything is pure user space applications we don't want anything in the kernel so in a Linux environment it's a it transits the system this service if you have a container and time whether it's cuber natives or darker or whatever it runs as a docker container if you have something like a third party proxy or if you are deploying a service mess or something else it programs the service mess of the third party proxies if you are running AWS lambda then it becomes a custom executable that allows you to actually provide the same come abilities on AWS lambda or it becomes an integration with api gateways of AWS and it allows you the exact same model across all these environments in reality most organizations are crossing all these boundaries right it's not that all my workloads are going to be kubernetes or it's not that all my workloads of Linux right we we allow this flexibility across the environment I'm one of the previous slides you have to go back on the previous slides we're talking about how if that enforcer service goes down you'll you'll throw resources they do you have the ability to run it in like an H a pair for like at BCD our context we don't actually need to because even if you have an AIDS a pair or you mean within a box ran it on an HCP no no not necessarily like a maybe of two separate Linux servers hosted in different environments to separate Linux servers will lead to be running an instance of the enforcer anyway okay because the enforcer only protects the processes that are local to this particular system okay it doesn't deal with any anybody else right so you need an enforcer on every horse store on every dark horse well right are you thinking about from the perspective of whoever's doing the master key management kind of thing yeah like you like HSN's best practice for its typical HSMs are to run to in pairs so if one goes down look at all the abilities data okay so the key management aspects then for sirs don't do any key management they are pretty dumb devices it's done but they are pretty simple a pretty simple software it doesn't have any state where is they there is a bootstrap mechanism all the identity and policy is managed through a centralized system so this centralized system now is running on an 8 a on an 8 a mode it's actually full micro service architecture that we will see in detail that scales to very large capacities and so on okay Tameka that makes person singing at them for services or the bottleneck no that happened you're like no we're down until we fix it no yes then forces are stateless ok ok state is maintained here and it's activate I'm actually gonna show pretty sure how this how this works so best practices for the aparato appliance or virtual points whatever it's it serves as that is in a trailer so these supported appliance since you brought it up it's not actually an appliance you have the option of us running it as a service in the cloud ourselves so our first offering is actually were the whole operator control plane with the identity dissemination and everything else Rance is a service and for large customers we give them a copy ascension of the service to run on Prem and the trans across multiple if transsexual at least across three servers it's a minimum installation right in order both for scallop for redundancy in case of a model I breed the architecture is better to run it locally I it depends actually still if you ask me right when somebody runs with our SAS model we go through a lot of pain to make sure it's secure and B we go through a lot of pain to make sure we update it constantly and so on right when you run it on Prem you get the overhead yourself right so there is this this thing usually the way it has been so far for us is that very security sensitive organizations and we have some of them they are like no we want to lock it down ourselves people that are smaller they're like we don't want to go through the question about the enforcer so we got your services we got your containers you're talking about micro services earlier is there also a code module of someone's role on their own and going server less that they could embed the enforcer service right we haven't done this yet it is on the on the plan on the roadmap the roadmap our first inclination was to say we need to keep this code separate yeah in order to get to be able to update it without changing the application or update application without changing the code however there is a reason to do it on the applications for in order to make it more more compact but again it's this requires developers to decide to adopt it and so on so it becomes a little bit of a friction point okay so I have one question it's a little outside of what we're going through here so I want to spend too much time on it but the the SAS model that you were explaining is essentially making aparato a third-party service provider to a lot of organizations so from that that perspective is a consultant I've seen a ton of organizations offer these types of services and it's start becoming issues with whether it be best practices or compliance regulations is a SAS provider from a third-party perspective what does a proto do to make sure that those identities are handled in an appropriate manner and not imposing threats just by the nature of it being SAS yeah good questions so there is obviously a whole security architecture and actually have at them of that too to illustrate what we're doing but let's forgive the technology for example we are actually going through a sock process ourselves okay in order to prove that we are compliant so that our customers can actually excuse me you guys do any cigs or anything like that or no yeah we are we're in the process I know that the length you know we're in the process sorry type 2 or yes well to start it to 2017 criteria yes it'll be the latest wear yeah okay I want to much harder so whoops does that destroy it yeah so now as I was saying what we do how do we do this authorization right and you will you will see the details of this we can do it at layer 3 level meaning it becomes if you want a replacement for micro segmentation type of things can this host open a TCP connection to that host that's the layer 3 type of level authorization will do we can do we can do it at layer out layer 4 this allows us to go transparently over l4 middle boxes and we do it at the API authorization layer where as I explained we can do it for every API call so how does this work now so this will give you an idea now a better idea of how the enforcers interact with the control plane how identities are created and how the route of trust is created so we start with our central control plane and we have a set of horst's down here right and the first thing is we bootstrap our and forceps now when an a4 set bootstraps it goes and gets for example in an AWS cloud or exhibit cloud environment it's going to go in the VM through a local API and get an identity document that is signed by the cloud provider it's they're gonna use this identity document to attest itself with a control plane and there's a result of this at the station process the control plane is going to return back a certificate down to the enforcer then force it is also going to create a private key locally stored in memory and it's gonna send this private key up there for signature so at the end of this process the enforcer essentially gets an enforcer identity a certificate an x.509 certificate and this certificate is stored in memory it's stored nowhere in the file system these certificates are ephemeral so they are they are automatically renewed by us constantly like every 30 minutes or whatever and they become the identity of the enforcer now an application pops up when the application pops up the enforcer goes and collects all the metadata of this application and creates a service identity for this application and then goes back to the policy system and one-time call and says what policy do you want me to apply down to this application right am I gonna apply I'm going to accept traffic for this or am I gonna be able to send traffic to this what are my authorization rules so it downloads the policy for this application local so oops so now how does how does authorization work at layer 3 this is actually an part of an open source project we have out there it's called trireme authorization of exchanging these identities as payload on the scene and cineq packets of tcp with zero RTT additional introduced to any TCP connection meaning what an application starts a TCP connection the TCP connection is intercepted by the enforcer the TCP syn packet is intercepted by the enforcer the enforcer gets the service identity and piggybacks this data of the payload of the syn packet that was otherwise 60 bytes sends it across the wire this enforcer receives the syn packet with a payload gets their identity cryptographically validates valid and the identity validates the policy authorization rules if it matches and lets the sim packet go to the kernel syn/ack packet comes back the cynic packet here again has no payload we get the identity now of this application piggy buggy this date on the payload of the cynic packet it arrives over here this enforcer now validates the identity and validates the authorization criteria releases the sin pack it in both the round-trips we have added nonces essentially one-time random numbers in random numbers and at the AK packet we send a signature across the two nonces and the reason we do that is because this allows us to prevent any money in the middle attacks through this three-way handshake so essentially when you do authorization at layer 3 it's a zero additional it's essentially zero RTT authorization that is happening for the connection before the connection is established there's gotta be some in your be enforcers grabbing it and you want to rewrite in them yeah yeah there is there is delay that we are adding right but I'm saying is there is no additional round-trip times that's what the zero R theta means right there are no additional round-trip time yes there is there is lay some additional latencies that we introduce and we'll we'll talk we'll actually see some results of this of this later thing what are the certificates changed to are they the whole PGI infrastructure is rooted at our control plane so the root CA actually the root CA is locked somewhere we have an intermediary CA so it's your it's your CA it's our saya this okay okay although we have the option of loading into the system's your CA or or any other media PK I select curricula and the certificate used to sign the JSON files or there is code signing certificate services it just what kind of certificate right so there but is really used is the public/private key bar but it yes it is actually a signature certificate okay okay and that's what is used by the enforcer thank you in order to do that the middle box is choke on the Sanderson AK packets once you've added payload I mean there so some middle boxes a l3 little boxes don't care so in l3 firewall and we actually have demonstrated with Walters and whatever they are fine however the world is not just all three middle boxes it's also a formidable box and all seven build boxes and that's where I'm coming next okay this works in an environment for example inside your data center inside your V PC where you are not crossing layers okay so as you very correctly recognized though this is not gonna cross all the middle box of this world because middle box is trivial so what we do but we actually have layer for authorization so how does the layer for authorization work well first of all there is the same bootstrap sequence that the enforcer comes as APIs identities come up and so on and then what happens is when the application creates a TCP connection we intercept this TCP connection and then we start a new TCP connection on the other side and then before the vision for Sur creates the TCP connection to the application they exchange identities we go over here and take chains identities we do authentication and authorization between these two entities and give these identities and the policy is approved then vision for Sur will start forwarding the TCP connection across the wire so what this allows us to do is actually cross therefore after them fight between between devices as part of it yes so if I want to do a TCP dump it's mostly useless to me after this point like in between Network disappea dump well no there's no easily to go and yeah let me explain actually whether you drink crimson or not by us there is an option it's a policy decision so if you turn on encryption by us then everything you are gonna see in the middle is encrypted mm-hmm and no easy way they're trying to play that back and then feel it keys through because my keys might change every 30 minutes lost your keys they all that all the keys and all the encryptions and so on is done with the ephemeral keys of constantly are constantly rotated right so there is no there is no replay or money the middle type order of things now because if I'm asked here's how it works with the middle boxes because so again the same story and forces a application starts a TCP connection is intercepted by the enforcer enforcer will attempt to do a TCP connection visiting the is intercepted by them the middle evil box the evil middle box will start TCP connection on the other side okay desire however that's where the evil finishes orthos then we're going to send the authorization information over the established TCP connection using the data payloads and once we authorize them to end the request we are going to allow the data to go through essentially and to end right so that's how we have solved the problem of the layer for middleboxes sorry which is the the other project about the layer free-riding trireme okay I read actually trireme the open source code includes all of this mechanism okay because all the forwarding your data mechanism that you are seeing here they are open source power and you are providing also some mechanisms to detect some brute force on the enforcer in case yeah I send payload so we different yes so it's actually I'm gonna do an interesting demo here where we put an NZ next server on the Internet protected by our enforcers a year ago and we have collected an unbelievable amount of body IP addresses that are doing scanning at very regular intervals ok so now as I go up the stack right again there are alpha beta boxes but network right and in reality especially as you move to a cloud native world a lot of people will use API gateways they will use layer 7 layer 7 load balancers and so on you will use all kinds of things in order to to achieve routing or service routing if you want for your application what we do at layer 7 is we repeat the exact same security model and to end at layer 7 what this means is when service run tries to talk to service 2 we can say service one can do a get on slash TLAs on /foo but it cannot do a post on slash on slash bar right so this is service to service api authorization the moment we do that we realize but we're also doing user to api authorization meaning if users come through a single sign mechanism are like open ID connect or any other such mechanized or if they have user x.509 certificates we use the exact same process in order to do user to service authorization what this enable essentially enables - it enables you to do is to use the exact same system in order to manage access of users to your application and delegate the authorization logic for your user authentication and authorization now delegate this logic down to what we do another interesting use case is this this is a micro services type of use case where you have service 1 and service - and you have a user in order for the user to actually operate or finish what they need to do they do a call on service 1 and when service 1 is going to do a call to service - on behalf of this user what we allow you to do in this environment is when the call goes between service 1 and service - to take into account for the authorization decision not just what is the identity of service Ron but also what is the identity of the user so when service one called service - on behalf of Bob it's going to say a completely different behavior than it fit call service Ron said well then if service one call service - on behalf of Alice and you will see some very specific use cases around that so if service one has makes that call and they have a different level of access or what have you then that user is that service that's calling on behalf of the user how's that privileged access right so the way it happens here the authorization decision here is made based on pou criteria what is the authorization that service one has when it comes to talk to service - let's say for example we have this last foo and slash bar api's service one has access to slothful ok in general only when it comes on behalf of user Alice service one doesn't have access to /foo when it's calling me on behalf of user Bob so let's make an assumption that service one has a different level of authorization than they use it's calling on behalf of does that service get elevated privileges not for that user no no it gets the combined privileges right in order to access the API you need the privileges of this and the privileges of this in order to access the API so if you need to combine the attributes if you want the combined scope okay so for the user to get to a strain I might be missing something here so I'm sorry if I will actually I have an example that I go away for that I think it'll clarify yeah okay actually the example is just coming one slide down the road so so first of all how does it work with API authorization is the same story of bootstrapping identities and service identities and so on we get an HTTP request now from the application into the enforcer or the enforcer will start a persistent TCP connection on the other side so it will start reusing the TCP connections for performance reasons and then what's going to happen is they to the P request gets trapped because of these HTTP requests getting trapped the enforcer is going to get the identity of this application and insert it on the HTTP request inject it on the HTTP request as an HTTP header so what is going to come across the wire here it's the same HTTP request on top of TLS that has the identity as as an HTTP header visits the P header will be validated by this enforcer and if it is accepted and approved the HTTP request is going to make it on the other side so essentially what I am trying to explain during this time is that you do it at layer 3 we have a solution we do it at layer 4 we transmit it over the TCP packets we do it at layer 7 the identity becomes an HTTP header no matter what layer you choose to enforce your policy we can map it to the corresponding identities over here ok so to answer your question about application and user identity so this is a UI right it's a server side let's say server side UI rendering application and this is a micro service and the requirements that we have is that the UI can access Alice on behalf of Alice however the you I must not access Alice / Sally's on behalf of Bob right so the way it works here is that when Alice tries to come into the system will automatically if Alice comes without authentication we automatically redirect Alice to an open-eyed provider Alice will authenticate with up an ID provider whether this is Google whether this is octa whether this is anybody else as a result of this authentication alice is gonna get back an auth token so alice is going to send us the earth talkin together with an HTTP request that says give me whatever is on slash Alice what is going to happen out on the wire is the identity that is going to travel on the wire here we could between this application and this application is going to be the JWT token that describes that this is Alice and the JWT talking that describes this is the UI application and the authorization rule on this API says that you can go to slice our lives if you present me a token that says this is Alex and you also present me a token that says this is the UI application if you just present me UI application token you're not gonna be able to access the API if you just present me an honest talk and you're not gonna be able to access the API okay does that make sense because when Bob comes because there is always Bob everywhere there is Alice what does the exact same thing and then Bob sends his de WT over his authorization token and then visualization request is dropped because the requirement is what you need to present is Alice and top equals UI not one of the two make sense of course it doesn't need to be Alice it can be the group that Alice belong so it can be any other attribute of factor so that server-side that back box right there is just simply passing that along connects okay I was I was thinking of the the possibility of and my TM from that box you know it was not given proper permission right that if it's just simply passing it on it's late okay right so okay then there is lambda functions lambda functions are much trickier there are no servers with where do you put the enforcer and all this kind of things we have a couple of implementations there what I will describe here is the integration we have done through the AWS API gateways so you have a request it can be a user request or it can be machine request whatever going to the AWS API gateway they have a capability they called custom authorizers what this custom of arises do is you configure the gateway when it gets a request it's actually going to call a lambda function that happens to be the operator lambda function to do the authorization and give the operator lambda function approved authorization then the API gateway will approve the authorization and the approved access is going to trigger another lambda function in other words even in the case where you have very flexible environments or very dynamic environments like lambda functions and so on we will get you the same identity the same identity and access management model is across everything else you are using in the organization last but not least and didn't asked about that performance right what what performance over guitar you guys introducing over this so here is the performance result I will be explaining to you what it is in case you cannot see it is this is an m4 x10 extra-large running in AWS why this particular because this particular one in AWS has up to 10 gig network throughput this is an m4 extra-large this has up to 1 gigabit network throughput right so this is the machines and what do you what you see here is you see the data of transmitting small requests here on the left and here on the left and you see the date of transmitting large requests on decide and what is happening here is what you will see is blue is native meaning there is no an operator enforcers in the middle there is no security mechanism well so ever that's what you get with blue green is when we actually do a TCP layer for proxy read this when we do a TCP layer for proxy and we do encryption ourselves and yellow or whatever this light color green is when you use the layer three type of connectivity that I described earlier now you see that for large payloads and lots of connections the performance impact is hardly noticeable across the board whether it's a full proxy whether it's encryption whether it's whatever the only place that there is a performance impact is when you have actually small connection requests and lots of small connection requests where when we insert the decryption we get the performance impact but that's kind of expected if you want because we have to to do all the encryption type of encryption type of functions however when you have persistent tcp sessions or lots of data are going across we pretty much are more or less equal or with whatever five percent penalty or whatever across a native type of implementation error in the way the screen is displaying how come with the m4x large encrypt is faster than not I'd say it's the scale is the way I'm looking at it yeah so yellow on the left is gigabits this is actually that's megabit yeah no I'm comparing these way I see no no yeah these with encrypted yeah so this is the measurement differences okay and it's also you know you get in you these are all tests are running AWS right so you know yeah since Jerry's fluctuations know is in a board who knows what else is happening over here this is just more to get a quick more work and now it's faster yeah exactly so it's more to get a qualitative sure I'm understanding of you know the absolute numbers for me don't mean anything yeah it's more yeah these so people adopt this if they choose to do the cloud based model they adopt it into a a premises model away wouldn't someone more like it's a sales type of approach where they adopt into it and is it multi-tenant where everything is a part of a multi-tenant structure or its individual tenants that are managed you know Ethan's a customer you core is a customer and then you have separate isolated tents so there's no chance for overlap within those it's a it's all a multi the SAS platform is all a multi-tenant platform and that's the interesting thing some of our customers are more in the service provider multi tenant category where they run an instance of these for their environment and they need to be multi tenant as well so the software is all of the tenant welcome last but not least monitoring as you understand where we are in the stock we have extreme visibility about the application we know what is running things like what libraries an application is running what calls is it doing what network activities is doing all this data we obviously as everybody everybody else right now that is a data hog we get all this data and we provide an extreme level of visibility of what is happening in the applications there is obviously a dashboard we are gonna see it in the demos that allows you to get full visibility of what is running right now in the infrastructure how they are related what are the related policies and so on and one item that a lot of our if you want more established enterprise customers asks less than devops type environments but the more established enterprise customers is okay we're going to deploy that we have no idea what policies to write right this is the classic the classic argument so the system we have established a mechanism where you can put the system in permissive mode it goes and learns it learns topologies it learns security in between the components and so on and it automatically auto-generate a baseline of policy that you can improve what you can modify after that so the way it works is that you deploy the enforcers the moment you deploy them forces you can put them in what we call design mode you start seeing what they are doing where are the vulnerabilities how they are interacting and so on you let this run based on the run you click a button you get a note of the narration of all the policies that need to be established and then you apply the policies and you turn off the permissive mode and you you see any alarm as a potential violation so this is kind of the usability tools we are I think of the first phases of these abilities we're adding a lot of this capabilities in the platform but this is where the platform is right now any questions before we close this part of the sessions how long do you recommend users take to create the baseline I don't have a good answer on that unfortunately because if you have an application that only does something let's say a backup once a week you need to write at least once a week right so you the longer you obviously running the better of you are but I think people the way people are adopting these things is more like okay put in permissive mode get visibility then we find the most acid the most critical acids and turn on policy there and then we watch it for a while and then we go to the next most critical asset and so on you can do it in tongues you don't need to do the whole thing at the same time it feels like enforcer is enforcer always in the data path or or not but is it just in the setup like you almost like control playing there's no separation then force there isn't it is only on the connection setup right you are doing the layer three okay model if you are crossing load balancer so they bi gateways or whatever it becomes a proxy yeah but still in the data path of that yeah correctly it's the data but then for cities it's another day for sure is always gonna be the enforce it is their sensitive the data path so the scale out for throughput or volume of connections or something I just didn't put more enforcers out there you essentially since you put 1 and 4 super server right and then four scales within the server obviously Oh proxy right so yes and actually that's a good question we don't run a site like if we are running in containers we don't inject a sidecar per container through the same way for example you're not gonna see two containers as opposed to one but what happens is the enforcer comes up detects the container and launches a child process that is dedicated to this particular container so the benefit of this is if this container starts misbehaving and the style process goes wild or whatever only this container is affected the other containers are not affected in the system so four processes is the same thing for every process every system this service in a Linux system we have dedicated controls with enforcer you go to a licensing or licensing is per server okay very instance running but enforcer is not running what does that mean exactly when you say per server or per instance running you know especially in serve real slow and I'm now yeah I used yeah so it's one license to rule them all unlicensed and multi-tenant so so the the licensing is very instance of the enforcer running somewhere okay okay okay so for example in they W is lambda there will be an instance of the enforcer running attach to the lambda the API gateway right so there's no theoretical way to provide on a single server multiple application instances that will be encrypted to talk to each other passing through it in order to minimize on your licensing costs no you could do that you could you could do it I mean if you if you're saying back all my applications in one server right so I have yeah you could do that but I don't hold him back virtualization I don't think our licensing costs are any major impact actually on all costs you actually see if back to the question I asked way in the beginning this still seems like many more policies than we would have in traditional microsegmentation it's actually by it's actually much less policies so let's think about it about the number of policies okay if we just want to achieve the basic micro segmentation type of thing right the policies is pretty much the same because you can say anybody on this would be saying that won't stop anybody on this VP see a lotta traffic yeah just take the day right because for example the VP CID is part of the identity so it just write policies based on the VP CID right so you can write very granule very coarse policies if you want now when you go to the API authorization layer the reality is that somebody is actually writing this policies already it just happens to be embedded into the application code very often right right so what we are saying is these policies can be externalized and managed centrally through the platform rather than every developer deciding what these policies look like okay the benefit you get out of this is that you get a global visibility across your layer 3 layer 4 layer 7 policies yes and the global correlation across all of them right so you know for example that or a developer can come in the platform and say well my application is not working because the network is blocking it is blocked somewhere at layer 3 or my application is not working because the API is blocked by somebody right so you get this visibility if you want across the stack so many more policies but the policies are more manageable because their central Miyoung and there were somewhere else before right somebody had to do them all you were not doing them to begin with and it's like a crime you get all another problem I got one other question for you now I'm thinking about DevOps model right let's say I'm rolling out some new micro services I'm changing something can I logically pool an area an app or service and say this put that back in to learn mode because my developers are going to push code out then switch it back on off learn mode so that maybe as part of a Jenkins workflow or something mm-hmm open it up I pushed it out they run it for a couple days it locks it down yeah absolutely so all these are knobs mmm you can actually put a policy that says this policy is only effective from 8 a.m. to 12 p.m. okay okay and then remove it good so my developers work 8 to 12 they get to do whatever they want exactly you can put time based policies you can put you can organize all this kind of things all right thank you

Channel: Tech Field Day

Views: 2,756

Rating: 4.8333335 out of 5

Keywords: Tech Field Day, TFD, Security Field Day, XFD, XFD1, Aporeto

Id: c02FyKVV-wQ

Length: 69min 38sec (4178 seconds)

Published: Fri Dec 14 2018