Zero Trust Security

[Applause] [Music] [Applause] [Music] hi i want to spend a little bit of time today talking about the hashicorp view on xero trust security what it means and what the implications of it are you know i think when we talk about zero trust networking it's helpful to almost take a step back and talk about what was the sort of traditional approach to security and what were the implications of that and so when we talk about you know the existing model that you predominantly see it's very much what i like to call sort of a castle and moat approach you have the sort of four walls of the data center and we bring all of our traffic over sort of the front door this is where our ingress and egress takes place and this becomes the single sort of choke point where we deploy everything from sort of firewalls web application filters sims etc so this is where all of our sort of networking gear goes and what we do is we create this sort of binary distinction right outside is bad and untrusted inside is good and high trust now in a large network we'd also segment this so we might have some coarse grained networks right this might be development staging production pci etc but these are still large network segments they might have thousands of nodes in each of them now as we try and go to cloud we add these nice fluffy cloud regions in and each of these we connect together into effectively the super network right the super network can be constructed from you know different networking technologies could be sd-wan vpn overlay direct connect express route etc it's really this concept that we're bridging it all together into one giant network now i think what you often see is how do we take this perimeter-based approach and extend it to these clouds right and get to a point where we have sort of a hundred percent effective perimeter here and i think what you find very quickly is if i'm going to give you any capability in the cloud i'm going to give you any i am permissions i'm giving you enough rope to hang yourself right and what i mean by that is i'm going to give you the right to create an s3 bucket for example you might define that s3 bucket and mark it as public in which case it's on the outside of your perimeter right in the same way that if you just change it to private it's on the inside of the perimeter so what you find is in cloud the perimeter is really a logical concept it doesn't exist in the same way it did on premise when you literally had four walls and a pipe coming in right everything was sort of you know inside your premise unless you explicitly made an effort to make it publicly accessible and so what you quickly start to realize is you know you really need to be comfortable making this 80 effective right and you can argue on exactly what that number is some if you're a pessimist you might say it's only 50 if you're an optimist you might say it's a 99 plus percent effective as long as you pick any number that's not a hundred percent you break this model of the world right and i think this model fundamentally was flawed to begin with right when we said it was a hundred percent effective there's sort of two critical assumptions here one is that of perfection right that i'm never going to miss make a mistake in my firewall and my web app filter i'm never going to have an out of date vulnerability i'm never going to have a zero day that's being exploited and so it requires a certain level of perfection that's not realistic the second is that it never contemplates an insider threat it doesn't matter how tall my you know my walls are how effective my firewall is if i've already given you you know a vpn credential and you work for me and you're a malicious employee or contractor or subcontractor right so i think there was two critical flaws in this model to begin with and so you know in many ways i think it's not a bad thing that as an industry we're now moving away from it so when we start to move towards this model where we say my perimeter is really you know less than 100 effective whatever that number is and i consider the fact that really my adversary might be on network already this is what brings you to fundamentally a zero trust networking model right and you can hear it be called different things low trust networking no trust networking etc the idea is that your core assumption is that your attacker is on your network and so you don't trust it it means we go away from this binary distinction of public untrusted private trusted right that binary distinction kind of goes away yes i still have a private network no i'm not making a distinction that that's a high trust environment in a way that the internet is not right they're all low trust no trust zero trust right so as we make this transition to sort of zero trust our view is that there's a few different pillars of it to consider right so starting at zero trust i think the next piece the question is well what do we use as the unit of control and what i mean by that is in this world in our traditional world the ip was the unit of control right if you were within our private network cider or subnets right those were considered high trust and you were authenticated if you're coming from the public internet those ips were untrusted right and so this might get expressed as something like a firewall control right the firewall is filtering you know which set of subnets and which set of ips are actually trusted but we're managing it through a set of ips versus as we move towards the sort of a zero truss setting we don't necessarily care about the ip because again we're moving away from this distinction at the same time as we go to these cloud environments they're much more dynamic much more ephemeral we're spinning workloads up and down so it's harder to manage a static set of ips and additionally as we're crossing these different networking boundaries ips might be getting rewritten we're going through gnats we're going through different middleware appliances so the ip is not a particularly portable or stable unit in that setting right so instead what we want to do is hang our controls on identity and when i talk about identity what i really mean is it could be application identity meaning this thing is a web server it could be human identity and saying this is armand armand is a you know database administrator as an example and so we're using identity as the basis of how we're defining these controls we would say our set of database administrators has access to our set of databases right that's an identity based control versus saying ip1 can talk to ip2 as an ip based control so to make this work our view is that there's four distinct pillars to think about right pillar one is how do i actually think about machine identity and so to make machine identity work i need a strong notion of what is a web server what is a database what is an api right and here is where volt plays so when we think about what the role of vault is it's first and foremost to provide a sense of application identity right so when we have application identity we can do this by integrating with all the different kind of platforms the vault will integrate with aws and google and azure and etc right it'll also integrate with our platforms things like kubernetes pivotal cloud foundry etc so no matter where these applications run we can map them in a consistent way into an identity and then define authorization rules on top of it right the most obvious application of this is great once we know that this thing is a web server and this thing is a database is we can use that for secret management so this is the common use case that people think about when they talk about volt is great i can use this to define you know you're a web server you get access to a database key you get a tls certificate you get an api token and vault can broker and manage the distribution of those secrets and credentials right so that becomes a pretty obvious use case the next one becomes data protection right so data protection again goes back to this model we have here right if we consider in this environment how we use to protect data we used to maybe have a web server and the users would give us let's say you know a credit card or some social security or something and then we'd write that to our database in plain text right so our database would store the credit card number or the address etc and if we were regulated we might use something like you know an hsm device and turn on transparent disk encryption so the database is encrypting its data at rest and so the threat model for this is really that someone knocks down the door of my data center finds the hard disk that has customer data pulls it out and exfiltrates it right what this doesn't contemplate is a network-based attack in this scenario if i'm an attacker and i can get to the database on the network and i can select data out from from that well transparent disk encrypt is also transparent disk decrypt right the database will happily read it from disk decrypt it and send it out over the wire right so it's clear in that case that it didn't really add much from a data protection standpoint if our threat is one of network and not one of a physical breach so in this last use case you really think about volt as a way of encrypting that data right so when that web server gets the unencrypted data it gets the credit card number the social security number etc that goes to vault vault then encrypts it with a set of encryption keys that it has it does not expose to the application and then it hands the safe cipher text back to the database i'm sorry to the web server and the web server can store that data in the database so in this case what we're storing in the database has already either been encrypted or tokenized so now even if an attacker can get to the database they need a second factor attack where they're able to be authenticated against vault and they need to be authorized to decrypt it or de-tokenize that data so really looking at in this sort of a zero trust world how do we think about data protection and how that evolves it's not enough for us to just consider that our database is behind the four walls or it's behind the perimeter we add those additional layers of you need specific authentication and authorization to decrypt that data as well right so that adds an additional layer of defense so this is where vault sits then the next challenge sits way on the other side of the spectrum right so on the other side of the spectrum is how do you think about human identity and this is a much more solved problem ultimately this boils down to basically single sign-on as well as having a common directory so in a previous generation this would have been largely active directory on premise serving this role now in a cloud world it might be azure ad might be octa might be ping might be centrify there's a lot of different answers but what it boils down to is i want a common directory of all my employees and maybe what groups are in so i know this is a set of dbas for example and then the single sign-on is i need some cryptographic way to assert that identity in other systems that might be oidc and i have a jot token that's signed it might be saml and i'm making an assertion about these users so there's a number of different tools and technologies but it kind of boils down to the same thing i need a common directory and i need some form of sso oidc saml etc that i can consume that identity in other systems once i have these two pieces i have a strong notion of who the people are that are identifying themselves and logging in and i have a strong notion of the applications and the machines and what their identities are then i have the two middle workflows right and there's kind of you know only two if we complete this matrix right which is one is machine to machine or app to app you might call it and the other is human to machine and so in both of these two use cases our challenge is how do we use the identities that we have and then use that to enforce control right and restrict who's allowed to talk to who so the authentication might be coming from the identities that we already have but then we're layering an authorization layer to make sure that only the apps that should talk to other apps do so and only the people that talk to apps talk to the apps that are supposed to so here is where console fits so console is hashicorp's service networking tool and there's really three key problems this solves right the first is service discovery and so with service discovery we start with the challenge of how do we even know what all of our applications are where are they in most environments there isn't really a catalog that says these are where all my apps are these are all the services that i have it's sort of an emergent property right there's things all over the place so the first thing console solves is it gives us a consistent catalog where we can integrate it with all of our different systems be they mainframe vm containerized serverless etc console integrates with all the different platforms and so it gives us kind of this bird's eye view of what everything is then on top of that you can implement a service mesh right so console can act as the central control plane where then we can define these central routing rules right so we can define rules and say great my web server is allowed to talk to my database my api is allowed to talk to my web right so that control again is an identity thing we're saying web server to database is allowed by talking about it at an identity level and then how do we enforce that well the way service meshes work under the hood is we're distributing a set of certificates to the different applications right that certificate encodes the identity right so the web server gets a circ that says it's a web server the database gets a certificate that says it's a database and it's cryptographically signed you know against a certificate authority that's trusted by our different nodes right and then the proxies when they communicate between one another so when the web server talks to the database it's going through a proxy similarly the database has a proxy terminating on behalf of it could be envoy h a proxy nginx the first thing those proxies do is they authenticate is this a valid certificate that's signed you know yes or no so now we have a strong notion of the identity on the two sides we know it's a web server talking to a database then the next layer is are they authorized so that's when the proxy will interact with console as sort of that central source of truth to say great i'm a database a web server is connecting to me is that allowed yes or no right and so now you can see what we're getting at is now we have an explicit control that we defined that says web server to database is allowed we're doing it at this identity based level we don't talk about ip1 to ip2 and we're using this mesh based approach to actually enforce that control right now it would be nice if all of our networks could just live in this mesh based world but in reality we have existing networks they operate in sort of an eyepiece-centric way we might have you know firewalls and gateways and wafts already implemented so the third piece here with console is what we refer to as network middleware automation or network infrastructure automation and the challenge here is i still want to define this identity based control that says web server talks to database but it might be that i'm not using a service mesh it might be that i have a firewall i have a palo alto firewall as an example in between them so in this use case what we would do is we would write a bit of terraform configuration so going as infrastructure as code to basically say hey my source inputs from console are the set of web servers and the set of databases and then given that i'm going to define how should my palo alto firewall be configured and so what that configuration then does we give that to console and so the moment a new web server is registered or a web server is deregistered or its health status changes console will detect that oh this bit of terraform code needs to be re-executed because it has a subscription or a dependency on the set of web servers or the set of databases and so this allows us to start with that catalog of we know all the different services as those things come and go we can trigger automation and use terraform to then update our firewall our gateways our you know various networking middleware devices and as part of this network infrastructure automation we've partnered closely with all of the major networking providers cisco juniper a10 checkpoint palo alto you know there's a longer list available on our website and so you can see how this then enables us to operate through this hybrid mode right where console's giving us the central catalog we can have our new green field applications operating in a pure service mesh and we can have that integrated to our more traditional networking environments using network infrastructure automation right so it gives us kind of a holistic way of moving towards this identity-based model of handling the machine-to-machine networking right then as we talk about the last use case it's about human to machine right and this is where our newest product boundary fits in and so when we talk about human to machine often there's sort of a gauntlet of steps users have to go through right they first have to connect to vpn or maybe they're going through an ssh bastion that puts them on the private network because we don't want them to have access to everything there's typically a firewall in place to restrict you know great if you're coming in from a vpn what set of network resources are you allowed to connect to so now you have to manage a set of firewall rules around who can connect to what right and then from there if i'm connecting to let's say a database i might want to do session recording or i need to have privileged access management to restrict who has access to database passwords so now i have to log in and use a privilege access management tool that might be imposing session recording and finally i connect to my target destination which might be the database right so we looked at that and said is there a way to simplify this where you just have a single point of entry and that's really what boundary is right so the idea is i don't have a separate set of vpn credentials i don't have to have a separate set of you know ssh keys i do a single sign-on right via my idp right so tie it back into this human identity we already have and that's how i authenticate i don't need a separate vpn or ssh credential right then the second piece is i really don't want to be in the business of managing three different sets of overlapping controls my vpn plus my firewall plus my pam plus my database i really want a logical control that says my database admins are allowed to talk to my databases right again going back to an identity based service based control and so that's how the authorization works here right so i have a logical sort of off the z that operates at that service level and that's how i specify who's allowed to do what right then the advantages boundary unlike a vpn or unlike ssh doesn't actually give you direct network access it won't put you on the network so i don't need a separate set of firewall controls boundary will only allow the user based on their authorization to talk directly to a target instance and that's happening from the boundary gateway directly to that instance there is no private network access and so we don't need a second level of firewall to restrict what you can do right so this eliminates multiple layers i don't need to first have a vpn and ssh i just talk directly to the boundary gateway i don't need another layer of firewall because i don't give you network access and then boundary can directly inject the credentials and in the future provide the session recording as well so i don't need a separate layer of privilege access management either right i talk from a user's point of view directly to the boundary gateway it authenticates me it authorizes me and connects directly to the target instance and because it's in that middle point it can inject the credentials as well as perform the session recording so it simplifies that end-to-end access right and so it's a simple solution that then covers the sort of end-to-end use case right otherwise we'd have three or four different pieces of control we'd have to interpose so taking a zoom out again as we talked about zero trust it's a much bigger space but it really starts with this idea of i don't want to provide any sort of a high trust assumption right i don't trust my network that means everything needs to be explicitly authenticated explicitly authorized and so if we're going to hang everything off of identity and the first starting points are do i have an understanding of human identity do i have an understanding of my machine identity once i have that i can leverage those to solve the two key networking flows right app to app or machine to machine using console and human to machine using boundary right so hopefully that gives you a sense of sort of how we think about zero trust and what we need in terms of the four pillars as we're transitioning to that thanks you

Channel: HashiCorp

Views: 8,355

Rating: 4.9298244 out of 5

Keywords: HashiCorp, Zero Trust, Zero Trust Security, Cybersecurity, Zero Trust networking, HashiCorp Vault, HashiCorp Boundary, Consul, HashiCorp Consul

Id: FCWl-1Q-GIQ

Length: 21min 5sec (1265 seconds)

Published: Thu Mar 25 2021