KeyConf NYC Interviews – 3 Security Challenges
David Spark: Mike, before we turned on the cameras here, you had 3 challenges and we are going to essentially pose these challenges to our audience. We’re not going to come up with the answers here. We have no answers.
Mike Wilkes: Yeah.
DS: But more we’re posing and so we want to know your thoughts on these challenges around secrets management. Give me the first one.
MW: Yeah, I think these aren’t rhetorical questions. These are real questions.
DS: No, yeah.
MW: So, my first thought in looking at the laying out of the problem and the description of the problem and the problem statement. Akeyless is a great place to help collapse some of our complexities of keys and secret management for humans and for machines. But I wonder if we weren’t able to do a good job with role-based access control, referred to as RBAC. In the past, when we had a perimeter-based model. Why when we suddenly moved to the cloud and do Zero Trust and we need to push that authorization and authentication out to the edge network. Why are we suddenly magically able to figure out what my permission should be?
DS: Can I throw out a suggestion here why, I think. Again, I’m not a practitioner but just hear what I think. The whole thing with the perimeter was it wasn’t as focused on identity as any kind of access management solution you’re looking at in general. And so, because of that, because this is more focused on the individual access versus more role based, that we are moving I guess more in a granular direction that the other solution didn’t have. Am I heading down the right road there?
MW: Yeah, I think you have the right instinctual response here, which is that perimeter-based security was often times hard and crunchy on the outside, soft and squishy on the inside.
MW: And so, you gave everyone admin once they were on the inside of the network.
MW: And everyone could talk to everything. Printers could talk to database servers. There’s a flat network topology usually and that legacy technical debt is now getting paid down because we can’t have that obviously, right, on the edge. You can’t just let everyone be an administrator and magically make the VPN go away and suddenly you’re secure. So, I think the challenge is that we don’t really have the discipline to assign and review access privileges at a granular level. Whether it’s on the edge in a Zero Trust architecture or whether it’s in a perimeter-based legacy model. So, that’s my first challenge.
DS: Challenge number two.
MW: The second question, I’m just curious about honey tokens. I think there’s a lot.
DS: So, let’s define honey tokens. It kind of sounds like Honeypot so it’s kind of the same idea and that would be.
MW: It’s in the same direction, right. So, we stand up Honeypots and we stand up deception infrastructure. If you have 50 real servers and you stand up fake servers, right. That the bad guys can attack, you’ve reduced your attack service by 50% because now as 100 servers, they could be hitting one of the other.
DS: But also, you can also start to understand their behavior too.
DS: And hopefully improve your security.
MW: And understand what they’re up to and what they’re after.
MW: So, lateral movement you don’t just want to eject them from the platform. You want to figure out what they’re up to. And so, I wonder if we could have a good discussion about honey tokens and tokens that are in your vault that if anyone ever uses it, it was a bad guy, right. Because no one’s using it and so you have to mix them in with your actual tokens and somehow administratively sign of stop them from being used, right. And that way you have breach detection. You have awareness of being confident.
DS: Now, would you purposely leave these Honey Tokens static or would you recycle them as you do the others.
MW: Or you could leave a few lying around on an S3 bucket and just see if someone randomly picks it up and then you have bad actor intent and to access potential. So, I thought that would be an interesting piece to add to the mix.
DS: But you know what, and also, I think what be interesting is to know how well your solution is standing up if you have the static honey tokens and you have the rotating honey tokens how are these two getting abused and at what rate.
MW: I mean if you’re getting any of them used, you’re in trouble but at least you’d like to know it.
DS: Right exactly.
MW: Yeah. And then third there’s an element of workflow I think that’s needed and in this case many years ago when I was working in the Chicago Mercantile Exchange. I thought that it would be great to have a password vault. And to link the password vault right your credential vault with your ticket system. So, that even if you did have a just in time provisioning of privileged access, you wouldn’t get it unless there was an open ticket assigned to you in service now or some other management system. That said, yes, and that’s the gating in authorization and control function. Because right now it’s great to have lease privilege and to have RBAC and to have you know one vault with a policy engine for machines and humans.
But without that workflow element, I still lack a level of control, which is that just because someone has the just in time credential doesn’t mean they should be using it at 3 o’clock on Tuesday. And so, that or today’s Wednesday, I guess.
DS: By the way no one watching knew that.
MW: Well, yeah that’s too, it’s not today by watching us probably. So, anyway I thought it would be useful to think about what are some of minimum requirements to do a key vault and have a policy that is tied in to your workflow management.
DS: Let’s summarize. First one is roll roll-based access control versus the key management solution. Why do we think we’re going to deal with this much better than the RBAC? I got that right?
MW: Yeah, we’re trying to solve the right problem finally of not having the perimeter-based soft and squishy on the inside piece.
DS: Second, and this more I’d be interested. Has anyone actually done Honey Tokens and what have you had as a result of that? I mean, do you know anyone who’s done it?
MW: Yeah, there are tools and platforms out there that set up what are called canaries and that have Honey Tokens and there’s an open-source project on GitHub called Space Iron. And it’d be great to try to integrate that potentially. So that you’re automating your token deployments in these native platforms and some of the tokens are no good so to speak.
DS: Okay and then the third is the process. How is this process folding into when secrets management comes into play?
MW: Yeah. So, you’re solving a good problem by having you know one policy engine for all of these types of authorization and credentials. And to have the audit log and to have fractional keys distributed and that all seems well architected. But like I said, the piece that I think is next required is to fit it into my actual workflow. Because I can’t just have a developer level up to a super admin at 3 AM at night, right, without an open ticket, that says yes you’re supposed to go fix this problem on a production server right now.
DS: How does just in time access when you work when you have anomalies? Like, what happens when there’s, well I guess they just create a ticket. Like I could create a ticket on this system which then opens up the key management system over here, that allows me to log in. Is that kind of the theory?
MW: It could go on that sequence, yes. You could also be having a request for a token and then that token or that just in time privilege credential is handed to you with the recorded session like we saw in the demo. SSH or RDP or MySQL database whatnot. Then it would pause before actually handing it to you and check an API against your workflow and say this user this system. So, you need to have good asset management, good configuration management database. Because otherwise those details aren’t in the ticket, right People mopping up a ticket, so you can touch production web. But there’s four separate servers, right. All four of the servers need to be enumerated to know which one you’re going to log in to and fix.
DS: Awesome. Mike, thank you so much.
MW: Thanks, David.