Scaling least privilege in the cloud remains challenging. Throwing more people at the problem isn’t feasible, so how are you managing it?

Check out this post for the discussion that is the basis of our conversation on this week’s episode co-hosted by me, David Spark (@dspark), the producer of CISO Series, and Geoff Belknap (@geoffbelknap), CISO, LinkedIn. Joining us is our sponsored guest, Sandy Bird, co-founder and CTO, Sonrai Security.

Got feedback? Join the conversation on LinkedIn.

Huge thanks to our sponsor, Sonrai Security

Full Transcript

[David Spark] Scaling least privilege in the cloud remains challenging. Throwing more people at the problem isn’t feasible. So how are you managing it? Welcome to Defense In Depth. My name is David Spark. I’m the producer of the CISO Series and joining me as my guest for this very episode is Geoff Belknap, the CISO of LinkedIn.

Geoff, say hello to the audience.

[Geoff Belknap] David, hello. Audience, how are you doing? You’re looking good today. You’ve been working out? Looks like you’re losing weight. Good job.

[David Spark] Why are you giving them more credit than me?

[Geoff Belknap] David, you always look amazing and are the paramount of health both mentally and physically, and I don’t want to embarrass you about how amazing you are.

[David Spark] But you just did. That’s exactly what you did. And I did work out this morning.

[Geoff Belknap] Well done. I’m very proud of you. I can see a difference.

[David Spark] Our sponsor for today’s episode, thrilled to have him back, is Sonrai Security. Enable one-click least privilege while supporting developer access needs without disrupting your business with the cloud permissions firewall. That’s theirs. And we’re going to be talking more about that later in the show.

And we’re going to be talking about permissions and least privilege today. So let’s talk about that. Implementing least privilege is always challenging. This is the whole industry on just this one topic alone, but since moving to the cloud, the sheer scale of this issue appears baffling. With a bevy of machine identities constantly being created, a human-mediated approach to least privilege just is not even possible.

So it’s easy to say we need to automate the process. But I’m going to ask you, Geoff, what does that kind of automation even look like in your mind?

[Geoff Belknap] There’s a good reason it’s hard to imagine because nobody’s really fully doing this yet. I think it’s part of why it’s a great excuse to have Sandy here as a guest. But I think what it looks like is all the stuff that we’ve gotten good at automating for end-users, thinking about building that into how we think about service identity or non-human identity, thinking about how we build into our cloud environment and thinking about how we scale it from where we could do user activity reports or one single human could understand what was happening to where machines can understand it and it can be built consistently, and you can build rules around it just like everything we do for detection and response in a network context.

Now we have to extend that to an identity context as well.

[David Spark] An excellent analogy right there. We do have an excellent guest to talk about this. And it comes from our sponsor guest. We had him on before on our other show CISO Series Podcast. So if you love him now, guess what? You can get bonus on our CISO Series Podcast episode where he was awesome on that.

So I’m thrilled he’s back. He’s the co-founder and CTO of Sonrai Security. You teased his name just moments ago. It is none other than Sandy Bird. Sandy, thank you so much for joining us.

[Sandy Bird] Thanks for having me. It’s great to be here.

Why is this relevant?

3:13.255

[David Spark] Jonathan Waldrop, CISO of The Weather Company, said, “Start small. Now we’re talking about least privilege. Begin by selecting one app or one permission in your environment to test the plan. From there, once you find success in not breaking things, continue and expand that process out to the next app or another level of control.

As you expand the program, you must have a solid process for requesting the permission. Who can approve granting the permission? What requirements should be met? How often do you review those permissions? There are plenty of tools that can help you automate this, sure, but I’ve seen automation break permissions and lock out valid users and admins.

Always plan for a well-secured and controlled break-the-glass account that is accessible in the event of a mishap.”

So this is a good, sort of methodical, logical way of approaching any type of new security rollout. Yes, Geoff.

[Geoff Belknap] It is. I think Jonathan’s giving you a master class in how to think about the theory of managing identity security. I think the part where I would diverge from Jonathan’s strong advice here is just to say I think the goal at this point for all of us is not to understand who understands a permission or what the plan is, but to build all your permissions and to build a platform in a way where you can assign those things programmatically, and no one has to understand them individually

 as a human to be able to manage those.

And I think, frankly, while I 100 percent agree that automation can break things, where we are today is we have to lean into solving that problem, not lean away from automation, but lean into how we build a more robust infrastructure. And I think Jonathan gives us some tips about how we might do that.

I don’t know if that’s the one I would use, but he is headed in the absolute right direction. Automation is where we need to go. And this is what it’s going to feel like if you are just starting.

[David Spark] And also, he’s talking about testing the waters, which is very wise. All right, Sandy, this is something you’ve actually done. Did you do a testing the waters technique like Jonathan did?

[Sandy Bird] Yeah, so we definitely always started. And again, my opinions have slightly changed over the last four years. So four years ago, I was definitely the purest: we’re going to automate this thing to death, we’re going to secure every permission, we’re going to create least privilege for every workload identity, we’re going to start on a small team, get them some tickets, build some reputable process, and it’s going to be amazing.

And over time, my stories have changed. My workflows have changed. And so I use this as my example. So in the simplest case of least privilege, talk about an identity that exists in the cloud that doesn’t even get used anymore. Hasn’t been used in 90 days, 100 days. Clearly, you need to get rid of it in a least privileged world.

And if we measure our customers, if you’ve been in the cloud for five or six years, probably like 70 percent or more of your identities are in this state, which is terrible. And so you go back to automation and say this is super simple. Why don’t we just delete them? We know how to automate deletion of an identity.

But when you actually ask the teams to go do this, they don’t do it. And here’s why: Aren’t you doing it? And it’s interesting in his question about the break-glass account. Okay, you have to know what your break-glass accounts are to make exemptions for them so you don’t delete them when they’re not used.

I had another example where a customer had a process that they knew ran to configure some device, I think it was a voice-over IP system or something at the time. And they said if we delete this, I don’t know how to put the permissions back. I don’t know how to keep the resource the same as the resource policies that allow it to happen.

I don’t know how to give it access back to the keys it needs. I don’t know how to do any of these things. So I can’t delete it. And so you end up with this scenario of we could automate it completely, we could delete the 10,000 unused identities. But if one of those is the break-glass account or one of them is this scenario where I can’t put it back when we need it, you just get this stalemate where they don’t do anything.

And so we’ve flipped our automation on its head. We’ve said, okay, let’s stop trying to do that. Cause people won’t do it at scale, and they won’t automate it. Instead. Let’s find a way to use this new term called zombies. Let’s put these zombies to sleep, quarantine them, basically cut them off so that they can’t do anything right now, but don’t take the permissions away.

Don’t take all of the configuration away, leave that in place. And so that way, when six months rolls around and you need to reanimate the zombie, you can do it. You basically can go and say, okay, turn this thing back on. We have this kind of cool process called permission on demand where you can wake them up when they try to do something.

And in that scenario, you can put 10,000 things to sleep, knowing that if you need to wake them back up, it’s as simple as a request and an approval to get it done. And that seems more palatable to people. They’re like, ah, I could do that. I can be comfortable with it. And that’s automation. And again, you can do the same thing for other scenarios as well, but I think it works really well to give them that small step.

And again, that’s automation. Start small. Try it in your dev account.

[David Spark] So now we know people are more comfortable with zombies than outright deaths.

[Sandy Bird] Yeah.

[Geoff Belknap] And that may be. I think it’s just a matter of what people are more afraid of. And I think I just want to highlight this point that Sandy made. Automation, and I make this mistake all the

 time because I’m over-focused perhaps on the control aspect of making changes and limiting permissions.

But automation is not just about that. It’s about visibility and understanding, right? Really managing the knowledge of your identity infrastructure. If you, right now, are listening to this podcast and you can honestly tell me you have a way to know which of those identities, STS, SAS tokens, whatever they might be, have not been used in the last 90 days that might be eligible for retirement.

I will call you a liar. Or I will ask you what tool, like Sonrai or something else, you’re using to get that visibility. Because today, that is a very difficult challenge, but that knowledge is super important. So automation does not have to be deleting these accounts manually. Some of it can just be getting real insight into how that identity information is configured today.

What’s going on?

9:41.128

[David Spark] Clement Chen of HiddenRoad said, “Least privilege needs to be done on both the control plane and the data plane. For the data plane, ABAC with resource tagging helps a lot. For the control plane, periodically analyze the logs and fine-tune the permission. AWS IAM access analyzer is a great tool for this purpose.

Netflix’s RepoKid automates the process to some degree. And last but not least, if you have hundreds of thousands of services to avoid IAM, that’s Identity Access Management, to avoid the IAM team from being a bottleneck, you’d likely need to enable each service team to manage their permissions. Use permission boundaries to set the maximum permissions allowed.”

And lastly, Samarth Rao of LinkedIn said, “Identify your most critical resources in the cloud and discover who has privileged access to its control and data plane. Once you have the inventory, enforce policies like periodic access review and just-in-time by opening a communication channel with owners and involving them in authoring proper just-in-time policies.

It’s critical we have proper tagging on resources to identify owners to ensure you don’t cause friction to the business and workflow as you do this. It’s easy for IAM teams to automate this as they know the lay of the land.” 

All right. This seems, does this seem overly complicated, or are they walking through a rather standard process here, Sandy?

[Sandy Bird] It was, there’s at least five different questions in there and five different probably answers to each one and as you say, it’s a complex process. But IAM has always been a complex process. I don’t think IAM’s ever been simple. And I actually can even add my own story to that. There was a part of that asked about make sure you have the approvers and make sure that it can be done quickly, and you can measure it.

And I had this great design partner we worked with when we were building this cloud permissions firewall and they said in our environment, everybody asked for contributor. And if you’re a contributor, basically, you can do anything that you want for whatever scope that you have it for. And he said the reason why is that to get a least privilege role or to get contributor is the exact same process.

I go through the same steps. I put the same JIRA tickets in it. I require the same approvals. So why would I ask for anything less than that? And so what happens is you end up with this massive expanding footprint, right? And this is to this point that you need to make the approval process really simple.

And not painful so that people don’t not want to stop and say, “Oh, I’m not going to do that. I’m going to just ask for the biggest thing.” And one of the things that we found when we started to look at all these cloud accounts were. If you looked at how they were laid out and who had access to the individual accounts and projects and all these parts.

You could actually predict who the approvers probably were but instead of making somebody just send a JIRA ticket in, have the cloud team go and actually provision access and change it and do all this stuff which took them days, by the time you get access you were two days late. If you could build it into the process where during I need to do this.

There was instantly a message in chat ops or something that says, “Okay, the approver’s been told you need it. They said “approve, go ahead and do it.” And that takes two minutes. All of a sudden, people didn’t ask for the world anymore. They asked for what they needed as opposed to the other side. And I think that was a good learning on our part to say you have to put this thing in line, right?

It has to be in line with the work, not some outside process. That’s interesting. And then to get into your co-worker at LinkedIn, I think the crown jewels thing is an interesting thing. It’s like the most important things are where you start with this thing. And if you do that, you will make sure that the right things are protected, right?

It’s almost the inverse of the “lose the forest for the tree” problem. It’s actually “don’t lose sight of the tree for the forest.” You need to understand that this is the most important tree, right? So I think those are just good points. As you go through this, there is a lot of concept in there.

We’re probably going to talk about attribute-based access somewhere in this conversation.

[David Spark] Both of them bring up the control plane and the data plane here as a different, I guess, a different approach. Is it a different approach if we’re dealing with identity here?

[Geoff Belknap] It’s certainly a different approach in terms of whether you would leverage something like just-in-time access. It’s a different approach in terms of, as Sandy was talking about, whether you would ever consider giving somebody contributor access or maybe overly broad access. Let’s be clear.

There are definitely times where, based on the consequences or the seriousness or criticality of the system, it might be okay to overprovision. But certainly when you’re talking about the control plane, to demystify what this really cool word sounds like, the control plane is generally the systems that control all your other systems.

That is not a level of your stack or your technical environment where you want to make an oopsie and overprovision somebody or let somebody have access that doesn’t need it anymore. In your data plane, where there’s the actual data that you’re using and typically where most of us are playing, it depends on what you’re doing.

I think it’s really important, as both Samarth and Clement point out here, to understand what your crown jewels might be and this is where that visibility into how identity works, what permissions look like in your environment, and how they’re granted is really important because what is a crown jewel may or may not be defined by something obvious: it’s really expensive or it would be really bad if it went down or was stolen.

A crown jewel might be a system nobody thinks about, but if that system went away or if that system was abused by abuse of permission or over-granting access, it could cripple your whole organization. A lot of time those things are hard to see. The other thing I’ll point out here and I just want to extend a great thought that Smarth had is just-in-time.

Just-in-time is one of these systems where you say, “Okay, because my role is whatever, a site reliability engineer, I should have access to system X, Y, and Z. But I should only have access when I need it, within a time-bounded window.” And when you set a policy like that, that enables you to do cool things like saying, “Okay, I don’t have access right now, but I need it in an hour for troubleshooting.

You can just click a button. You don’t necessarily need approval. You click a button, you get access for an hour. Now, it might be reviewed later, and it might generate some logs, but just doing that work, setting it up so it’s self-service like that reduces that demand for over-provisioned accounts.

It reduces people’s crutch and reliance from a sort of an emotional perspective on break-glass accounts. And it really improves the security and resiliency over time of your environment.

Sponsor – Sonrai Security

16:33.299

[David Spark] Before I go any further, I do want to tell you about our awesome sponsor. That’s Sandy’s company, Sonrai Security. Now, do you know what’s more old school than blowing on a Nintendo cartridge to make it work? Many listeners know where I’m going with this. Manually creating individual policies to achieve least privilege in your cloud.

Leave old habits in the past; that’s ancient. Nobody does this anymore. And lock down access to sensitive permissions and services without disrupting DevOps with a single click with the cloud permissions firewall. This is Sonrai’s thing. You can easily restrict excessive permissions from human and machine identities, quarantine unused identities, and restrict specific regions and unused services with.

Once again, the click of a button. Continue maintaining this level of security by automatically enforcing policies as new accounts, roles, permissions, and services are added to your environment.

See how easy it can be achieved. This least privilege you can do it. You can start a 14-day free trial with Sonrai’s Cloud Permissions Firewall Act. It’s Sonrai.co/CISO. Go check it out.

What aspects haven’t been considered?

18:03.374

Vaughan Shanks of Cydarm Technologie said, “An exponential proliferation of resources makes a complex challenge for managing least privilege. Typical role-based access control or RBAC results in a combinatoric explosion of roles, which is hard to manage. 

Now, an alternative approach,” is what Sandy was talking about earlier that we’re going to get to and we’re getting to it now, “Attribute-based access control or ABAC. Government entities have used ABAC for a long time to successfully apply least privilege. The need-to-know principle by applying labels to documents or portions of documents. ABAC scales better than RBAC, and the recently released cloud best practices guidance from NSA and CISA reminds us that ABAC is a key element for zero-trust maturity.

You can apply ABAC to manage. Access to control-based resources by utilizing tags as attributes on resources and group memberships as attributes on user principles and service principles.” 

And lastly, let me just mention Mauricio Ortiz of Merck said, “To secure or limit access to something effectively, the how first you must know what and where is your most valuable data and workloads.”

Ah, calling about to call back to crown jewels. 

“You must have a solid data inventory, then you can work on your IAM policies with a least privilege principle mindset and leverage RBAC and or ABAC. Third, you must continuously audit, monitor, identify activities, and audit logs to refine the policies or address gaps using tools like CNAPS or CSPMs.

All right. This is a mouthful that I and a lot of advice both Vaughn and Mauricio offered. Walk us through RBAC and ABAC. How are we using them best, Sandy?

[Sandy Bird] Look, I have had this interesting flip-flop of opinions on ABAC access as it applies to AWS over the last several years. I remember when Amazon got very and they started adding this functionality into Amazon and a lot of the really advanced customers were super excited about it because you could control access, everybody comes in as the administrator but then only if through session injection or through a principle tag or there’s all kinds of different ways to do it.

If you had a certain tag on your identity or this thing injected in your session, you would be able to read the data out of this database or whatever the resource was. And I was like. That’s interesting and all, but you’ve given every developer in your world the ability to add or remove any tag from anything that they want, and so theoretically, they can escalate their own privileges by just changing the tags on things, and I’m like, I don’t know how you’re going to control this thing.

And when you looked at it, a lot of people failed the implementation of it because of those reasons. Actually, they just couldn’t figure out how they could wrap all the right controls around to it. But this goes back to our first topic we talk about automation. The controls that control ABAC also allow you to put the controls in place through automation to make sure that you have good strong tagging.

So again, back to Vaughn’s comment and in the LinkedIn comment around having proper tagging and having these things. And if you have that in place properly, ABAC is actually a really strong model. Now here’s the tricky part with the clouds. The model in AWS and Azure and GCP are completely and utterly different with different sets of rules.

And so what you learn in one cloud doesn’t apply to the other. So it is a big learning curve to get that stuff going. But it does allow this scale to data and to resources and to permissions that are really hard to do using the standard RBAC models, right? Role-based access control where you’re just granting somebody contributor at a subscription or you’re just giving them editor rights in a GCP project.

The ABAC allows you to reduce that set down. There was somebody that mentioned permission boundaries too which is another way to reduce these scopes. I think it’s a great way to do it. I think it’s super powerful. But you have to be very careful not to get it wrong because the ability to self-escalate by small mistakes like oh, giving somebody the permission to add a tag now becomes very problematic in terms of self-escalation.

So again, super strong and they actually are very powerful. I’ve seen amazing implementations but you got to be careful.

[David Spark] Geoff, Sandy brings up the issue of tagging data. And we’ve actually talked about this before that once your data is clean and tagged and you categorize heck, there’s a world of things you can do at that point, right?

[Geoff Belknap] Yeah, look if I have unlimited money and people, I can also do all kinds of things. I think the what’s the joke? If my grandmother was a boat, she would float also yeah that’s true. Let’s just zoom out for a second. Look at the conversation we’re having. You as the listener, when we started this, you may have thought identity and access management, ah, this is kid stuff.

This is not the real hard work in InfoSec.

[David Spark] Although I don’t think anyone thinks this is fully solved by any stretch.

[Geoff Belknap] Yeah, no, it’s not solved. I think instead what people think is

, this is not the sexy stuff in InfoSec. This is identity access management. That’s not where the best people go. Those aren’t real engineers. And certainly, to be clear, this is not me saying this. This is me pretending to be somebody else saying this.

[David Spark] Somebody else that you don’t agree with, but the words are coming out of your mouth. Okay, I got it.

[Geoff Belknap] So when this gets edited, when this gets edited later to make me look foolish, just know the full context was here. So what I’m trying to say is, this stuff is really complicated, and it is probably one of the most fundamental things that you have to get right if you want your security program to really be worth it.

To be worth all the time, sweat, and blood, and tears that you put into a security program. This stuff is complicated, and it is. Complicated by a multiple by exponential impact at scale. And that scale is not, you don’t have to be a LinkedIn or Microsoft organization to be dealing with the complexity of scale.

You really just have to be in the cloud or across multiple public clouds. And maybe Azure isn’t your favorite, maybe you add some other stuff into the mix, that’s okay. But what it does is add incredible complexity to the work that you have to do. And the only way you can get good at this is by having great people and great automation there.

And the only way you’re going to build that automation is by understanding that. And this brings it all the way back to your original question, David, which is tagging the data, super important? It is. And this is a thing where you have to get it right at the beginning. Otherwise, you are going to be chasing your tail for years to get it in the place where you can make best use of automation.

Whose issue is this?

25:10.916

[David Spark] Amit Arora of Amazon Web Services said, “Guardrails and more guardrails, and monitoring and more monitoring, evaluation and more evaluation. And a break-glass mechanism because no one wants a bottleneck when your developer wants to debug a compute instance which is infected with malwares in production. And the guardrails around break-glass and monitor and more monitor.” 

So all good advice. I think though this break-glass metaphor that we brought up at the beginning of the show sounds great, but Amit puts a good comment here. It’s don’t let your break-glass be the open hole that can break the entire environment.

[Geoff Belknap] Yeah, this is a little like saying you could develop safe crypto with a backdoor. No, somebody will use the backdoor. If you build your entire identity system around the idea that it’s super great, but there’s a break-glass system, I will tell you the professional adversaries know that you have at least one break-glass account and that is all they are looking for.

They are looking for that break-glass. They are not going to spend time trying to frontally attack you. So just know that’s what you’re getting into when you make that decision. Yes, I understand it is very difficult to get to the point where you can live without a break-glass account, but that should be your target.

You should not be imagining living with it forever.

[Sandy Bird] I was gonna say I agree, Geoff. We would love to get rid of them. In some ways, I think the Amazon guys even make it really hard to get rid of them. Getting rid of those accounts is almost an impossibility. Hopefully, you just create the MFA token and throw it away somewhere, but in those ones.

But the reality is, I think you’re right. Again, we have to get to the point that even the most privileged users have some sets of checks and bounds and a real identity system to prove who they are when they’re in making changes. And we say privilege. What’s this is where I think the workload identity and the people identities have this weird blend that’s happened over the last five years.

We talk about break-glass, but then you have and we saw this through a red team exercise in a customer where they got a hold of something in GitHub that they could execute a Git runner. But the Git runner ran as basically the deploy role in the cloud. So now, using this highly privileged deploy role, which is like break-glass, it’s deploying all the infrastructure and doing the things.

They were able to, of course, create a backdoor in the cloud. Lucky it was their own red team. So that’s easy enough to deal with. But you look at that and you’re like, did the build role in the middle of the week when this happened, not during a deploy window. Really need access to do something that no one in the cloud even ever does, and so you need these secondary levels of control on this.

And I think Geoff has a great point. We’ve got to try to get rid of some of these standing administrator permissions that are there for what’s theoretically an emergency or a deploy process. And during the times when that’s not happening, they’re just sitting there for the adversary to grab and use for a bad purpose.

And again, one of the reasons we did this cloud permissions firewall was this denied by default state, right when you have 100 teams building and they’re all building identities and they’re all opening things up all the time, but they don’t use 95 percent of the sensitive things that they’re provisioning at any given one point in time.

The first time that’s used, there should be a check and balance there, right? And so by putting that check and balance in and saying, do you want to approve this thing when it’s denied? No. Yeah, I do. Yes, I don’t. Whatever you can make that choice. And that becomes one of those indicators that then you feed to your SIMS or XDR platform whatever acronym we want to use today to say no, that’s funny.

We just denied this. And why did it happen in the middle of the week? That seems odd. So I think good comments by a minute. We need lots of this stuff, but we’ve got to try to do better in terms of the standing forever full admin permission for these things all the time.

[David Spark] I think we’re in full agreement here that this complex issue that we thought was very complex at the beginning, at the end of the show, it’s still complex.

[Geoff Belknap] Probably even more so than we thought.

Closing

25:10.916

[David Spark] Yeah. I would hope that we’d solve all the problems, but I know that Sonrai Security has a lot of great solutions for this, and we’re going to get to that in just a moment. But we come to the point of the show, Sandy, where I ask you which quote was your favorite and why, and you can you could just summarize why you liked one person’s quote over another and who was it?

[Sandy Bird] Look, I think I go back to Jonathan and the Weather Network. I think through this, and I’m like, this idea of starting small is an interesting concept because you build the muscle memory to do it over and over again. We have this new product, this cloud permissions firewall, but when we envisioned the design of it, we build it such that it just defaults goes in a monitor mode.

So back to Geoff’s visibility comments, you got to have visibility. But what was interesting about it was you could start anywhere in your cloud hierarchy and just say, “I just want to take one dev team and try this,” and I can have the full functionality of everything it does but only in that one corner.

Yeah. And when you get it right and you’re like, this is really good, it was low friction. In a couple of days, we got to the point where we’re actually making real progress. You could quickly expand it to the rest of the teams and the rest of the cloud. And it has nothing to do with, in some ways, least privilege or any of these things.

It has to do with the fact that the design of the product is set up to start small and expand quickly. And I think our design partners appreciated that maybe even more than the fact that it did a great job at reducing the sensitive permissions that they had out there.

[David Spark] All right, excellent choice. Your favorite quote and why, Geoff?

[Geoff Belknap] It’s a tough choice, but there’s this guy, Samarth Rao, from LinkedIn thought he made some really solid points. I’ve never heard of this guy. LinkedIn’s interesting-sounding company.

[David Spark] What was the point he made that you liked so much?

[Geoff Belknap] I really liked that Samarth showed up on this. Hey Samarth.

But I really like the idea about just-in-time. People often forget that you have an in-between access and no access. There doesn’t have to be permanent standing access. And while Samarth makes some great points, I’m not going to read it; it’s a long quote about understanding your environment.

And instead of thinking of crown jewels, I might say think about prioritizing the assets that you’re protecting and the permissions and strategies whether ABAC or RBAC is right for you. But just-in-time permissioning is a fantastic way to give people a bump in the wire. Like how Sandy was talking about, you can have something that denies but gives you permission to allow it in an emergency situation or in a one-off.

Just-in-time is a way to set it up and say, “Hey, If you only need temporary access, you’re approved for that, but you only have it while you need it. It’s not sitting around waiting for you to be asleep and for an adversary to use it while you weren’t using it. It’s off until you absolutely need it.

And then when you’re done with it, it is off again. That is a great program to build. And it’s a great intermediary while you’re waiting to get either your attributes and your documents or your data all tagged or whatever you need to do. It’s an excellent maturity step to take.

[David Spark] Great advice from both of you. I want to thank your company, Sandy, Sonrai Security, which enables one-click privilege while supporting developer access needs without disruption with your cloud permissions firewall. Remember, go to Sonrai.co spelled S O N R A I. That’s how you spell Sonrai, Sonrai.co slash CISO.

And you can start your 14-day trial of that Sunrai Cloud permissions firewall. Sandy, any last words, anything else besides what I have just said you’d like to say to our audience?

[Sandy Bird] Now, look, I think there’s lots of great information on the website and think even back to Geoff’s point on the just-in-time. One of the most amazing things I learned building this just-in-time permission for a firewall or whatever you want to call it for building this kind of firewall, we actually had design partners say for things like machine identities, things that deploy stuff once a week, once a month, whatever, they were starting to think about just-in-time for that.

And we always thought about just-in-time for people. And I was like, that’s an interesting concept. I never really thought about just-in-time for machines, but it actually does apply for certain workloads. And they’re usually the ones that are really privileged to actually do that stuff. So I don’t know, look forward to the next year and see if just-in-time expands between people identities and machine identities.

[David Spark] That is actually an excellent point and a great place to end this conversation. Thank you very much, Sandy Bird, who’s the CTO and co-founder of Sonrai Security. Geoff Belknap, he’s the CISO over at LinkedIn. I’m David Spark, just the guy who runs the CISO Series which you are hopefully enjoying now.

And if you enjoyed this show, guess what? We got tons more shows on the network. So check us out at CISOseries.com. Thank you as always for contributing and listening to Defense In Depth.