bsideslv zero trust - Cloudinary › peerlyst › image › upload › v... · Lots of 3rd party networks between sensitive systems Presents large security challenge Must provide

Evan Gilman, Doug Barth

@evan2645@dougbarth

Zero Trust Networks

8/3/17

@evan2645@dougbarth

About Us

Zero Trust: Building Systems in Untrusted Networks

Both SRE’s, met at PDDoug hails from SWE backgroundI come with background in computer networksBut right now, Doug is SRE @ Stripe,And I am working on FOSS project SPIFFE

8/3/17

@evan2645@dougbarth

About Us


Both joined PD w/in a couple months of each otherPD still pretty young, fairly small infraI’m sure everyone here knows what PD does…So, goes w/o saying, availability is important

8/3/17

@evan2645@dougbarth

About Us


Availability req is the basis for this storyKey business driver for ZT implementation at PD(Contrary to popular belief)So… how did we get started on ZT?? (Interesting story)

8/3/17

@evan2645@dougbarth

DC-A

DC-B DC-C

C*

C* C*


PD hosted in multiple providers and regions to meet avail. goalsEach dotted line represents boundary between geographically-disparate region/providerEven though infra small back then, still challenging

8/3/17

@evan2645@dougbarth

DC-A

DC-B DC-C

C*

C* C*


All clusters were active/active cross-regionLots of 3rd party networks between sensitive systemsPresents large security challengeMust provide access control + confidentiality for majority of flows

8/3/17

@evan2645@dougbarth

DC-A

DC-B DC-C

C*

C* C*


Chose to automate access control firstEssentially just wanted SGsExcept SG’s are AWS-specific, Region-specificWe needed same functionality but cross-cloud…

@evan2645@dougbarth

iptables

so we built iptables automation into ChefProvided SG-like semantics based on Chef roleCustom LWRP to declare policyChef crunches the declared policy into iptables rules

@evan2645@dougbarth

Here is an example…Executed on webserver to allow access from LBProvided most of the flexibility we needed…With access control (somewhat) addressed, wanted to turn to privacy

@evan2645@dougbarth

Like iptables, all encryption configured by hand (case-by-case basis)Needed blanket encryption, easy to use, “just works”VPN is most popular solution…

@evan2645@dougbarth

IPsec VPN

For PD architecture, typical VPN brings many challengesVPN typically deployed as site-to-site tunnelsActive/Active PD infra means lots of cross-dc talk…

8/3/17

@evan2645@dougbarth

DC-A DC-B

DC-C


VPN

VPN

VPN

… so VPN tunnels will be heavily utilizedThis brings scalability and availability concernsAdditionally, not all providers have VPC-like functionalityLack of private network forces hub/spoke model w/in a DC

8/3/17

@evan2645@dougbarth

DC-A DC-B

DC-C


VPN

VPN

VPN

All of these things combined give us a lot of overheadDidn’t really even care about routing… just wanted securitySo we decided to drop the VPN…(4m elapsed)

@evan2645@dougbarth

IPsec VPN

And keep just the IPsec partEnded up deploying raw IPsec in transport modeConfigured as full mesh (opportunistic)

8/3/17

@evan2645@dougbarth

DC-A DC-B

DC-C


VPN

VPN

VPN

So the network goes from looking like this…… (next slide) to this

8/3/17

@evan2645@dougbarth

DC-A DC-B

DC-C


Mutual authentication occurs when first packet is sentEncryption applied transparently from there onKernel configured to drop all non-IPsec packetsAll benefits of VPN security without VPN itself

8/3/17

@evan2645@dougbarth

DC-A DC-B

DC-C


So, we got confidentiality w/ ipsecgot access control w/ iptables + ipsec…but when put together, the system exhibit interesting properties…

8/3/17

@evan2645@dougbarth

Emergent Properties

All Flows Authenticated and Encrypted

All Flows Asserted as Authorized

No Inherent Value in IP Address


read slide……… but perhaps most interesting set of properties is…

8/3/17

@evan2645@dougbarth

Emergent Properties

No Centralized Firewalls

No Network Gateways

No Private Network


… that the network has no (read slide) centralized firewalls(read slide)Essentially, we had succeeded in building a secure perimeterless networkIt was around this time that BeyondCorp paper was published…

@evan2645@dougbarth

BeyondCorp

Paper described google’s perimeterless corporate networkThey had been working on it for a number of years by thenSeries of papers released since then, describe unmanageable corporate perimeter…

@evan2645@dougbarth

BeyondCorp

Grown too large and permeableIneffective at stopping most modern threatsExciting for us to read, lots of similar principlesValidated a lot of early PD security decisions

@evan2645@dougbarth

BeyondCorp

Not only validate, but demonstrates another use case (client side)Broader application of similar philosophiesHelped us understand full scope/implications of the model, which we now call ZT…

@evan2645@dougbarth

BeyondCorp

Doug and I gave a pair of talks on the model and its reasoningShortly thereafter, opportunity to write a book on itDon’t like writing, but excited because so little out thereWith that, I’d like to invite up DougHe’s gonna talk a bit about the ZT model itself…

@evan2645@dougbarth

Zero Trust Philosophy:

No Trust In Network

(0/5) ZT model is fairly simpleSimply stated: “Assume the network is hostile”b/c hostile: Want to remove trust from the network…(9m elapsed)

@evan2645@dougbarth


No Trust In Network

(1/5) Meaning: position in the network is insufficient for authn/authzDramatically changes network security arch.Need to authn/authz everything: users, devices, applications…

@evan2645@dougbarth


No Trust In Network

(1/5) Least privilege becomes pervasive throughout the networkPrefer large number of small f/w’s over small number of largeForcing function towards distributing enforcement

@evan2645@dougbarth


Every Flow Is Expected

(2/5) Only authentic/authorized traffic is generally acceptedOnly flows explicitly authorized by policy will be allowedAll unauthenticated and/or unauthorized traffic is treated as exceptional (either dropped or redirected for remediation)(Ex. User’s need to authenticate w/ dedicated device, or device being bootstrapped)

@evan2645@dougbarth


Symbolic Policy

(3/5) Policy defines which flows are expectedBut, policy shouldn’t be defined in terms of network primitives (position is insufficient)Instead, we want symbolic policy which follows the workload(we can calculate implementation details)…

@evan2645@dougbarth


Symbolic Policy

(3/5) PD and Google both used DSL to define policyEnforcement rules calculated from DSL based on contextDSL not mandatory - key is policy/enforcement separationEx: AWS Security Groups: db SG references app SG

@evan2645@dougbarth


Network Agent

(4/5) User, device, application authentication are all required in order to do this effectivelyTreated as a unified concern for authZShould AuthN each component separatelyPolicy authZ is written directly against the agent…

@evan2645@dougbarth


Network Agent

(4/5) this better capture the desired behavior of the systemExample: authentic user on phone can do strictly less than authentic user on issued laptop…

@evan2645@dougbarth


Automate!

(5/5) Full automation of security processes is importantInfeasible to accomplish such an arch. otherwiseAutomation makes it easy to do the right thing…

@evan2645@dougbarth


Automate!

(5/5) Boils down to continuous realization of policy in an ever-changing system(Workload moves, system reconfigures itself)Without automation, sacrifices will be madeThere’s more than just enforcement for ZT though……

@evan2645@dougbarth

Visibility

Logging and analysis of all traffic is critical for risk analysis and forensicsGood news: ZT infra can make this easier to doZT provides many hooks for logging/eventingKnowing what to expect can help drive alerting configuration: corporate laptop is doing odd stuffStart of feedback system which adjusts to novel threats…

@evan2645@dougbarth

Start Early

Strong ZT network practically necessitates whitelist approachRecommendation: Start capturing policy early 1) low overhead to maintain, high overhead to build 2) challenge is greater the larger the system 3) can reach a point where enormous effort req’d to migrate

@evan2645@dougbarth

Start Early

Flip on enforcement as soon as you canHelps ensure whitelist reflects reality…Can be hard to visualize from such a high levelWanted to give some real-world implementation examples

@evan2645@dougbarth

Manifestation

How do you actually do this? What does it look like?There are obviously critical functions…almost certainly several systems involvedcontrol plane separation typically shakes outhas handful of responsibilities…

8/3/17

@evan2645@dougbarth

Control Plane Services


User Inventory

Device Inventory

Data Plane

ServersServersServers

ServersServersPhones

ServersServersLaptops

Most obvious of which is to track user and device identityNeed to authenticate both in ZT networkNetwork agent (from earlier)… need source of truthdata will drive most ZT decisionsmost important pieces? required…

8/3/17

@evan2645@dougbarth



User Inventory

Device Inventory

Config Mgmt

Data Plane




some have CM in control planeex: pull device data to dynamically enforce policies…… then push into data plane for enforcement… another critical piece of the control plane is authn/authz…

8/3/17

@evan2645@dougbarth



User Inventory

Device Inventory

Config Mgmt

Authentication Services

Data Plane




can be many services/protocolsex: SSO or even IKEBacked by both user and device inventory(To form network agent)This is a very basic/contrived example…

8/3/17

@evan2645@dougbarth



User Inventory

Device Inventory

Config Mgmt

Authentication Services

Data Plane




Can get much more advanced than thisAlso missing some detail ex: manifestation in data planeWe have two real-world implementations we’d like to share…

@evan2645@dougbarth

Examples

Important to note these networks can take on different formsdiff goals + business needs == diff implementationsbiggest diff… solving for client side, server side, or both?

@evan2645@dougbarth

Server-Side

Client side and server side have very different challengesFor now, useful to focus on one at a timeWe’ll start with a server side ZT implementation done by PD(Evan will talk to you later about Client-Side)

8/3/17

@evan2645@dougbarth

PagerDutyChef Cookbook for Initial Implementation


PD, like all startups, began with the simplest thing that could workUsed Chef cookbooks to calculate and apply policyChef server was the device inventory system

8/3/17

@evan2645@dougbarth


Maturation brought Specialization


System grew and that approach had poor scaling and isolation guaranteesPush to multi-tenant container workloads exacerbated the issueSo we started extracting known behavior into a new dedicated system

8/3/17

@evan2645@dougbarth


Maturation brought Specialization

Topology-Manager


That system was called topology managerMade up of control and data plane componentsLet’s explore it now

8/3/17

@evan2645@dougbarth

Topology-Manager


Control Plane

Data PlaneServerAgent

Contained Workload

ServerAgent

Contained Workload

Enforcement

Agent responsible for local network security configurationreceives updates from device inventorychanges local policies in responseAll enforcement happens locally (no network control, after all)…

8/3/17

@evan2645@dougbarth

Topology-Manager


Control Plane


Contained Workload

ServerAgent

Contained Workload

Enforcement

Traffic secured with device-oriented IPsec policyOnly authenticated IPsec traffic is acceptedall other traffic is dropped… device authentication + flow security is provided by IPsec… … But what about the workloads?

8/3/17

@evan2645@dougbarth

Topology-Manager


Control Plane


Contained Workload

ServerAgent

Contained Workload

Enforcement

Two things we do to secure this layer…1) topology-manager configured w/ workload information(including type + associated policies)… then… it uses this to

8/3/17

@evan2645@dougbarth

Topology-Manager


Control Plane


Contained Workload

ServerAgent

Contained Workload

Enforcement

configure iptables rules, based on attached policyThe second is the use of vaultIt maintains app-level service accounts. more on this in a sec…Topology-manager handles all ZT operations, except calls to vault

8/3/17

@evan2645@dougbarth

Topology-Manager


Control Plane


Contained Workload

ServerAgent

Contained Workload

Enforcement

so now we know what the data plane looks likelet’s see how the control plane is set up…

8/3/17

@evan2645@dougbarth

Topology-Manager


Data Plane

Control Plane

server-side has some interesting characteristicshosts can be cycled out more easily, you know what to expect from them, etcmost changes driven by introduction of new host or workloadhost provisioning case as an example…

8/3/17

@evan2645@dougbarth

Topology-Manager


Data Plane

Control Plane

Authorized User

we’ll start with an authorized userremember, control plane very sensitivewant to tightly control write access to ituser is on an authenticated device, and has provided correct password + TOTPsends request to a provisioning service…

8/3/17

@evan2645@dougbarth

Topology-Manager


Data Plane

Control Plane

Provisioner Authorized User

the provisioning service authorizes the request, then takes series of actionsThe first is to actually create the cloud instanceUser provides an image and a provider/DCProvisioner works out api calls, etcOnce the instance has been created…

8/3/17

@evan2645@dougbarth

Topology-Manager


Data Plane

Control Plane

Provisioner

Device Inventory

Authorized User

the provisioner registers it into the device inventoryinformation like type of device, IP address, etcdevice inventory subsequently pushes updates to agents…… which reconfigure IPsec and iptables to allow the new host, if necessary

8/3/17

@evan2645@dougbarth

Topology-Manager


Data Plane

Control Plane

Provisioner

Device Inventory

User Inventory

Authorized User

Next, the provisioner contacts the user inventory(again) a little awkward in server-sideIn this case, the “inventory” is hashicorp vaultprovisioner registers new device and tag it with secret mgmt policies…

8/3/17

@evan2645@dougbarth

Topology-Manager


Data Plane

Control Plane

Provisioner

Device Inventory

User Inventory

Authorized User

When the app comes up, it contacts vault using device credentialsuser accounts are automatically created and tracked by vaultwhich provides the app with session credentialsbut, app has to know how to talk to VaultIn the case of legacy services…

8/3/17

@evan2645@dougbarth

Topology-Manager


Data Plane

Control Plane

Provisioner

Device Inventory

User Inventory

Config Mgmt

Authorized User

CM leveraged to provide credentials (Still backed by vault, just abstracted)CM is still relevant, but we’ve removed some responsibility. eg. configures topology-manager, and installs supplemental policy when necessaryThis is pretty much entirety of PD ZT infraSo, what did they accomplish with it?

8/3/17

@evan2645@dougbarth

Topology-Manager

No Trust In Network


Well, they definitely accomplished no trust in the networkNo perimeter security devices, fully perimeter-lessMassively simplifies multi-cloud deploymentNever have to think about DC-to-DC connectivity (really cool)

8/3/17

@evan2645@dougbarth

Topology-Manager

No Trust In Network

Compute Can Be Bootstrapped Anywhere


In addition to multi-cloud simplicity, this setup brings extreme agilityCan turn up new datacenters triviallySince no connectivity to configure…… simply teach the provisioner about the new DC

8/3/17

@evan2645@dougbarth

Topology-Manager

No Trust In Network

Compute Can Be Bootstrapped Anywhere

All Flows Get Strong AuthN/AuthZ


Every packet encrypted and authenticated, no exceptionflows gain further authz through the fine-grained iptables rules(in some cases, even restricting source ports)User mgmt + authentication is automated by vault with short-lived credentialsSo now that we know what server-side looks like…

@evan2645@dougbarth

Client-Side

I’ll ask Evan to come back up to look at a client-side implementation… (evan)Evan: Thanks Doug :)(Next slide) (33m elapsed)

@evan2645@dougbarth

Client-Side

Client-side is very different from server side for a couple reasonsThe first is that clients are wild they often act in unexpected ways…another difficulty comes in their mobility…

@evan2645@dougbarth

Client-Side

can’t predict where a session will come from, (often) must listen for allCan expose authentication service’s attack surface to the internetfinally, clients act as ‘hybrid’ ZT clientthey will almost certainly interact with non-ZT resources…

@evan2645@dougbarth

Client-Side

because of that (and because device theft is easy), user authentication is very importantGoogle beyondcorp is good examplerelatively-mature client-side implementation(but hard to tell due to secrecy)

8/3/17

@evan2645@dougbarth

GoogleLarge Network, Large Perimeter


very large corporate networklarge network means even larger perimetertens of thousands of users…… accessing thousands of resources(just a guess… maybe more?)

8/3/17

@evan2645@dougbarth


Many Remote Employees


In addition, they have many remote employeesNot just full time, but traveling employees and at-home access too!How many visitors might Google campus see on daily basis?Perimeter worked ok when all work was physically performed at a business location…but how true is that today?

8/3/17

@evan2645@dougbarth



Perimeter + Remote Access Untenable


when framed like this, it’s clear that these systems have not scaled wellthe perimeter is too permeableand once inside, elevated access can be enjoyedGoogle recognized that this model doesn’t work as well as it once did…

8/3/17

@evan2645@dougbarth



Perimeter + Remote Access Untenable

BeyondCorp


And launched the BeyondCorp projectBeyondCorp aimed to move corporate network to zero trust modelRemoving perimeters and untrusting the corporate network works to ease the painsSo let’s dig into how Google built its client-side Zero Trust implementation…

8/3/17

@evan2645@dougbarth

BeyondCorp


Control Plane

Data Plane

Corp. Client

it’s natural to start at the client :)So here we have a client…It’s a user coupled with a deviceWhen a request is first made, the user gets sent to an IDP for authentication…

8/3/17

@evan2645@dougbarth

BeyondCorp


Control Plane

Data Plane

Corp. Client

undergo typical user authentication stepsusername + password + totp (check this)this part is basically regular SSOafter authenticating, next step is to contact access proxy…

8/3/17

@evan2645@dougbarth

BeyondCorp


Control Plane

Data Plane

Access ProxyCorp. Client

when doing so, a client certificate is presented (serves to authenticate the device)client negotiates mTLS w/ the access proxyproxy authenticates request using device pub key + user ID from SSO…also uses this information to…

8/3/17

@evan2645@dougbarth

BeyondCorp


Control Plane

Data Plane

Access ProxyCorp. Client

Enforcement

… to authorize the requestIt passes details about the request to a control plane service…… which considers the identifiers + associated policyMakes authorization decision, which proxy enforcesOnce authorization succeeds…

8/3/17

@evan2645@dougbarth

BeyondCorp


Control Plane

Data Plane

Access ProxyCorp. Client BackendBackendBackend

Enforcement

the connection is forwarded to a backend serviceconnection to backend is protected and trustedbut, distinctly not zero trustclear delineation between security models…

8/3/17

@evan2645@dougbarth

BeyondCorp


Control Plane

Data Plane


Enforcement

So we can see that the data plane is fairly simpleLet’s take a look at the control plane…

8/3/17

@evan2645@dougbarth

BeyondCorp


Data Plane

Control Plane

User Inventory

Of course, there is a user inventoryRecords lots of user metadata, including role at company etcBacks several services, one of which is… (generic sso)

8/3/17

@evan2645@dougbarth

BeyondCorp


Data Plane

Control PlaneSSO

User Inventory

Clients are redirected to SSO if a user hasn’t authenticated yetWorks like your typical SSO providerThe client will be kicked back to the proxy following authenticationIn addition to user inventory (of course), is a… (device inventory)

8/3/17

@evan2645@dougbarth

BeyondCorp


Data Plane

Control PlaneSSO

Device InventoryUser Inventory

Device inventory is more challenging in the physical worldParticularly challenging in client-side deploymentMany different types of devicesDesktops may even change parts aroundCan be hard to keep track of…

8/3/17

@evan2645@dougbarth

BeyondCorp


Data Plane

Control PlaneSSO


Still an important piece, despite challengesBut instead of pushing data to an agent…… Google pushes device information into something they call an…… “Access Control Engine”…

8/3/17

@evan2645@dougbarth

BeyondCorp


Data Plane

Control PlaneAccess Control

EngineSSO


access control engine powers all authorization decisions in googles ZT networkit pulls data from both user and device inventorycan be loaded with both coarse and fine grained policyconsiders both data sources when making authorization decisions

8/3/17

@evan2645@dougbarth

BeyondCorp


Data Plane


EngineSSO


… so while the access proxy can validate authentication…… it passes identifiers up to the access control engine for proper authorizationAccess control engine is flexible, and can support a variety of inputsSo, with systems arranged in this way, they can back ZT guarantees in the data plane.now… Even though diff implementation from PD deployment…

8/3/17

@evan2645@dougbarth

BeyondCorp

No Trust In Network


Many of the same outcomes are achievedThere is no longer trust in the corporate networkin other words…corporate network no different than the internet.No perimeter required…

8/3/17

@evan2645@dougbarth

BeyondCorp

No Trust In Network

Users Safely Roam Free


it also freed users of VPN requirementsnow they can travel wherever they need to, and still access critical apps“Internet” mobilityRemote workers don’t require clunky s/w, visitors and intruders don’t gain extra accessand finally, similar to our server-side deployment

8/3/17

@evan2645@dougbarth

BeyondCorp

No Trust In Network


All Requests Get Strong AuthN/AuthZ


All requests are strongly authenticated and authorizedProxy has advantage of being L7 though…Google proxy can and does authorize every request, as opposed to every flowYou can see how different these approaches are…(Same goals…)

8/3/17

@evan2645@dougbarth

BeyondCorp

No Trust In Network


All Requests Get Strong AuthN/AuthZ


But they achieve the same basic goalsSame guarantees Doug spoke about are present here…So it becomes apparent - two sides of same coinThat said, we can do even better than this…

@evan2645@dougbarth

Mature Zero Trust

The things we just discussed are only the min. req'sa mature ZT network includes services beyond min requirementnamely, takes risk into accountBeyondCorp has indeed taken steps into this domain…(45m elapsed)

8/3/17

@evan2645@dougbarth

BeyondCorp


Data Plane


EngineSSO

Device InventoryUser Inventory Trust Engine

Introduced “Trust Inference” service…This service calculates risk based on a number of factors…… like the kind of device making the request…… or perhaps an OS which does not have a particular security patch…All of these inputs get added up to create a score…

8/3/17

@evan2645@dougbarth

BeyondCorp


Data Plane


EngineSSO

Device InventoryUser Inventory Trust Engine

that score is used in addition to “traditional” policyhelps policy writer catch unknown unknownspolicy can include traditional constraints plus a min scorethis helps keep “suspicious” requests out, (ones which otherwise would be accepted)as an additional concession…

8/3/17

@evan2645@dougbarth

BeyondCorp


Control Plane

Data Plane


Score

Score

The access control engine passes the score down to the access proxythe access proxy then injects the score (along w/ other info, as L7 header/tag)This allows backend service to make fine-grained authorization decisionsCan take this one step further even…

8/3/17

@evan2645@dougbarth

Mature Zero Trust


Trust Engine

User Data

Device Data

and integrate behavioral heuristicsso for device behavior…

8/3/17

@evan2645@dougbarth

Mature Zero Trust


Trust Engine

User Data sFlowDevice

Data

… perhaps you might use sFlowor a similar network sampling protocolAnd for users…

8/3/17

@evan2645@dougbarth

Mature Zero Trust


Trust Engine

User Data sFlow AccountingDevice

Data

… perhaps that’s “regular” user accountingMeasuring things like successful and failed logins over timeBoth of these (device + user behavior) can give really good confidence signalsFunneling them through behavioral analysis can give very meaningful resultsResults from these considerations can then affect trust score appropriately

@evan2645@dougbarth

UX is Important

It’s ultra important to maintain good UX in these schemesNot just in daily ZT operation, but in migration tooGreat care should be taken to minimize false positives (if using scoring)Exceptions will be normal, plan for themgood news is…

@evan2645@dougbarth

UX is Important

ZT generally improves UXauthn/authz is automated, only surfacing the “regular” user auth interfacesusers don’t have to fool with vpn connectionsso in the end, it’s actually easier to useNow, the reality is…

@evan2645@dougbarth

Earth is Calling…

all of this stuff is pretty newsome of it not even realizedex: no client-side + server-side implementation!Doug and i have only build server-side…

@evan2645@dougbarth

Earth is Calling…

Dozens of callsfrom practitioners to researchers to CTOsBecause reality is, we (industry) don’t really know all the answers…

@evan2645@dougbarth

Current State

ZT network is still mostly roll-your-ownSome good tools and building blocks, but must be put togetherVision is large, likely to require multiple pieces of softwareStill very early, lots of opportunity, very promising…

@evan2645@dougbarth

Current State

So… yea :)Who is crazy enough to do this? Good question…We can roughly split ZT deployments into two categories: client + serverDistinction made due to difference in implementation (client behaves very differently than server) (server has more control)In terms of client-side implementations…

@evan2645@dougbarth

we have companies like Coca-Cola, Mazda, and Google (beyondcorp) Coca-Cola for rapid provisioning of branch officesMazda for fleet phone-homesGoogle for raw security and scalabilityand on the server side…

@evan2645@dougbarth

we have companies like Lyft, Square, and of course PagerDutyMost adopt for raw security, PD adopted for multi-cloud (cloud mobility)But all have rolled their own…… there are however some commercial options for various components…

@evan2645@dougbarth

Aporeto, SPIFFE, and Edgewise working on ZT problems in datacenter (AKA server-to-server)Cryptzone, Vidder, and Waverly Labs working on client-side ZT problems (SDP)And then ScaleFT and Duo also on client-side ZT problems (BeyondCorp)….

@evan2645@dougbarth

All these vendors provide ZT componentsStill, no end-to-end solution, not mutually exclusive…

8/3/17

@evan2645@dougbarth

Just The FactsIndustry Moving Towards Deep Authn/Authz

Industry Converging on Zero Trust Model

More Secure, More Operable

Keep an Eye Out!


Take all this together… not hard to see: hiding behind perimeter alone undermines system securityIndustry is moving towards deep authn/authz to compensate for holes (in perimeter model)Will eventually converge on the ZT model (happening already)…

8/3/17

@evan2645@dougbarth




Keep an Eye Out!


Some products more ambitious than othersBut as mentioned, will likely manifest as many systems working together to realize ZT model…the end result is more secure, more operable systemKeep an eye and an ear out, new things happening every week…

8/3/17

@evan2645@dougbarth




Keep an Eye Out!


If you’re interested to talk more, we’ll be around for a while…That’s all we’ve got for you today, thank you very much for coming… (pause)Evan - come back up for Q&A?

Evan Gilman, Doug Barth

@evan2645@dougbarth

Zero Trust Networks

Go back!

Documents

bsideslv zero trust - Cloudinary › peerlyst › image › upload › v... · Lots of 3rd party networks between sensitive systems Presents large security challenge Must provide