KeyConf NYC Interviews – The 3 J’s of Zero Trust

David Spark: Alright, I am talking to Dr Zero Trust. Chase, just give me the low down. Just 30 seconds, tell me what was your presentation about?

Dr. Chase Cunningham: It was really about using access management to take back the initiative from the adversary and then some very basic sort of principles to apply that actually change the game for everybody else.

DS: Zero Trust, the term has been very hot. You hear a lot of vendors using it in their sales, even the governments come on board. And is suggesting highly recommending that all companies move towards a Zero Trust architecture. Now the question is what does that mean? I’ve heard a lot of definitions. I want to hear your take on this.

CC: Sure, so the Department of Homeland Security I believe is actually formally establishing a Zero Trust office in December, which is pretty significant.

DS: Yeah, that is significant.

CC: First time, that’s happened as far as I know history of the US DOD. So, that’s kind of interesting. I tell people all the time Texas Kid, right. I say don’t trust nothing, like that’s one of the major things the tagline. But the other side of it is, it can be simple and that’s what I talked about in this talk was just justify why just in time and just once. If you can do those things and access management, you’re enabling Zero Trust.

DS: Alright. So, let’s walk through all three of those stages. Justify why, what does that mean?

CC: If someone’s trying to access something for some reason, there should be a way with a policy engine to go, why is this occurring? Is this a valid reason for this to happen and if it’s not, there should be something on the other end of that. And it sounds complicated, but you already kind of live this way if you think about it. A lot of times when you try and access your bank, there will be a reason your bank may kick you out because something looks weird. So, they’re trying to find a justification of that to occur. And that if you do that, you think about from the adversary perspective. If I’m a bad guy, I don’t know why you need to access something. So, that’s a key thing can take the power away from the adversary.

DS: So, I want to isolate that just a little bit more. How can I sort of create a valid justification for someone coming in. I don’t know what I should be asking or what criteria I should look at like. I and I’m assuming that’s going to change individual to individual and so, am I creating more problems than I need?

CC: You’re creating more problems than you need if you try and do this without technology that operates at this scale, which is a very valid point. If you really look at it though, the majority of I guess you would say threatening sort of reasons that this would occur it would be a problem. Those are going to be administrator type things or access developers, whatever else. That’s more of a small sort of valley wick to deal with when you’re talking about the reasons why they need to access something. Your common everyday user consumer type thing, that’s a sort of a different animal to describe.

DS: So, can you, just give me an example? Give me an example of where you would ask some kind of justification question. I don’t know how that presents itself and how you could exclude someone who shouldn’t be in and include someone that is. And then at the same time, not create too much layer of complexity to prevent someone from doing their job.

CC: So, remember, there’s other things tied to this but this for this justify side. So, let’s say you’re a developer and you’re working on a project and you need to go remote to something to do some developer, whatever developer thing. Basically, what you’re doing is you’re bouncing that against whatever system has got that contract or that project registered in it. Saying, is this a valid request and do they actually need to get to that for the purposes of this job? As long as that’s validated, okay, justified.

DS: And how does that justification change when you’re dealing with humans and you’re dealing with machines?

CC: Machines are actually, I like machines even more in this scenario because machines are pretty binary. They do something because there’s a reason for it to occur in the first place. So, this machine should SSH to that machine. There’s a reason for it because they’re in the same project group that type of thing. So, it’s very similar in the sort of multi-factor authentication thing. I’m doing something out of band to make sure that this is supposed to happen.

DS: And is this really an exercise in rules management? Any does it because again, I’m fearing this is going to become too complicated. How does this get set up where I’m not essentially overwhelming myself with rules?

CC: Policy, you need a really good policy engine and you got to be able to do this at speed and scale and this is where I want to go on the consultative side of the workshops and whatever else. I would rather spend my time making sure that that policy engine is crafted for these types of problems first then like you’re saying, deal with it after the facts. So, that’s part of the curve of doing this is you do that first and make sure that it’s really well situated, so that that isn’t on the farm.

DS: Right. Deal with it earlier than later shift left whatever you want to call it. Alright, let’s go to second stage just in time.

CC: You should get access to something because there’s a reason and you should get access and there’s got to be a time horizon to it. It shouldn’t be infinite access. It shouldn’t be. Yes. Weeks, months, years, whatever. It’s most of the time it’s going to be a session-based thing. When you’re connected to me that for that that session, it’s good. Once that session is terminated because that’s how systems work, the next time it’s for that next session. It’s not continuous.

DS: So, yeah. So, this falls under the category of Privileged Access Management.

CC: Yeah.

DS: Alright and then justified, just in time, and then just once.

CC: Right.

DS: So, which is tied I think to the second one.

CC: Exactly and that’s I remind people like if you think about it like your house, right. Somebody walks up and says, I need access to your house to fix an electrical issue. Okay, cool. There’s a reason for you to be here. You can be here for an hour. Go fix your electrical thing. They show up an hour later. I’m going to justify why. I’m going to let them in and then just that one time, they come back in and then they leave again. Like that’s the whole concept.

DS: To me, it seems step two and three are reasonably easy. Step one is the hardest because you’re dealing with so much policy. Is that really the case?

CC: Yeah, and what you also find too from organizations that do this correctly and are using the technology correctly, the policy engines, the rule sets like you’re saying, they get better as you do this more. So, when you first start, why don’t I rely to anybody? It’ll be a little blippy. You’ll have some issues you have to fix. Okay, fine but as you do this more and as you continually craft this thing, it becomes better and easier.

DS: Excellent. Well, Chase, thank you so much for joining us. I was speaking with Dr. Chase Cunningham, Doctor Zero Trust.