Follow me:
Listen on:

Day Two Cloud 178: Implementing Zero Standing Privilege (Sponsored)

Episode 178

Play episode

Welcome to Day Two Cloud! On today’s show we examine the concept of zero standing privilege with sponsor strongDM. StrongDM is a security tool that gives you seamless access to the infrastructure you manage. Zero standing privilege goes beyond just-in-time credentials to a model where no credentials pre-exist, but are created in real-time and paired with appropriate permissions built from policy, also created in real-time.

That’s a “maximum security” point of view, and like a lot of security paradigms, it’s an idealistic one. Practically speaking, can zero standing privilege actually be implemented in the average organization?

Our guest today is strongDM’s Sebastian Mankowski. Sebastian has a really good handle on the organizational challenges of implementing zero standing privilege, and how to work within them while still getting the security posture result we’re looking for. This episode is a follow-up from an earlier sponsored podcast with strongDM.

We discuss:

  • The concept of zero standing privilege
  • How zero standing privilege fits into zero trust
  • Technical hurdles to overcome for zero standing privilege
  • How to get buy-in from users
  • Writing zero standing privilege policies
  • More

Show Links:

Day Two Cloud 172: Lock Down Access With Zero Standing Privilege (Sponsored Podcast) – Packet Pushers

@strongdm on Twitter


Welcome to day two. Cloud. Today’s episode is a follow up to the last show we did with Strong DM. Strong DM is a security tool that gives you seamless access to the infrastructure you manage. And in that last episode, Strong DM pitched the idea of zero standing privilege. Zero standing privilege goes beyond just in time credentials to a model where no credentials preexist but are created in real time and paired with the appropriate permissions built from policy, also created in real time. I think I got that right. That is a maximum security point of view. And like a lot of security paradigms, it’s kind of an idealistic one, because, practically speaking, can zero standing privilege actually be implemented in the average organization? Our guest today is strong. DM’s sebastian Mankowski Sebastian has a really good handle of the organizational challenges of implementing zero standing privilege and how to work within them while still getting the security posture results we are looking for. Sebastian, welcome to the show. I set you up with a tall order here, man, to take an arguably inconvenient security posture and implement it in an organization. And none of us seem to like inconvenience.

[00:01:17.500] – Ethan
We really don’t. So we’re going to talk about this, how to implement zero standing privilege. But we should refresh everyone’s memory first on what zero standing privilege is, because maybe you folks have heard of just in time privileges, but you guys are making a distinction at Strong DM between just in time privileges and zero standing privileges. So could you tell us what the difference is between those two?

[00:01:39.470] – Sebastian
Yeah, for sure. Thanks for having me, Ethan and Ned. Appreciate you taking the time to let me just hear myself talk. Always good to have a little extra time for that. I think that at its core, where I always start in terms of thinking about the differences, is just in time often is part of your road towards achieving zero standing privileges. So rather than them being things that live at odds to each other, zero standing privileges is a framework or an end point that just in time privileges can help you achieve. The biggest differentiator being that zero standing privileges is this world where there is no concept of standing privileged. There’s no notion of a world where users within your infrastructure framework constantly have access to anything. Anytime they need access to a thing, whether it’s a service, whether it’s a serverless or database, they request access to it. And that allows for essentially a type of continuous authentication that occurs at the identity and user level rather than just the connection level. So you can check things like what is the posture of the device, what are the characteristics of the identity that is attempting to request access or privileges to a particular resource?

[00:02:59.220] – Sebastian
You can evaluate that all in real time without ever having to rely on a set of permanent or standing privileges.

[00:03:06.890] – Ned
Okay, so if I’m understanding correctly. Let me read that back to you. In a just in time situation, they always have the privilege to access the resource. It’s just that you’re opening up the gate for a certain amount of time for them to leverage that privilege. But the privilege is always there, whereas in zero standing privilege, the privilege isn’t there. It’s defined in a policy somewhere and then applied as needed when access is requested to that object. Did I get it right?

[00:03:38.150] – Sebastian
Yeah, I think that’s a great way to reframe it. And the notion of there being policy that governs how a user’s need for access gets instantiated at any given point in time, I think is the best way to think about it. It’s like you have this rather than explicitly having discrete sets of privileges that you’ve allocated towards individuals, you’re instead saying ned is a member of the SRE team and when pager duty says that he is on schedule and there is an incident. These are the sets of production resources that he should be able to access as long as he conducts an MFA event. And then he can go in and resolve any problem for the duration of the incident. So you’re essentially describing a problem. You’re describing the need of what somebody’s doing and then having what is explicitly needed to accomplish that goal to solve for that problem flow from that policy, from that description of the problem.

[00:04:31.500] – Ethan
You just put something together for me that I was missing before. Wasn’t quite set in my head. That is, Ned could have different privileges at different times depending on the role he’s playing at any given time. An on call is a great example. What you might need on on call to solve a problem is different than what you might need for your daily admin duties or what you might need when you’re subbing for someone who’s on vacation, let’s say.

[00:04:56.750] – Sebastian
Yeah, exactly. And I think that’s maybe a subtle distinction, but to me a very valuable one. I think historically, notions of pam and zero trust very much rely on this concept of the access itself. Ethan can access this database as being your discrete building block, and everything else is just a collection of those pieces of access. And you’re managing those pieces when in reality, those are kind of an artifact that we’ve just created out of necessity. It was something that was needed, given the systems that we had at the time, in order to actually implement what is the true nature of the problem, which is Ethan, at any given point in time in the day, needs to do his job. In order to do his job successfully, he needs to access these tools and resources. What are those? How do we understand them? And then how do we just make sure it’s still Ethan when he is needing to do those jobs and then just let everything connect the dots between them rather than having to try and manipulate and worry about the discrete components themselves. Those are kind of just an unnecessary artifact at this point.

[00:06:01.250] – Ethan
Okay, we’re using the term zero standing privilege and of course, zero and zero trust, those ring certain bells in the minds of security professionals these days. So how does zero standing privilege fit into a zero trust scheme?

[00:06:12.810] – Sebastian
Sebastian so this is something where we’re entering in a world of philosophy and terminology that I think you could have five people in a room at a bar and have seven different opinions. But from my perspective, I see zero streaming privilege as the gold standard of what one might accomplish with a zero trust mindset. Again, in terms of specific definitions, I think it’s one in which there will be a lot of variance in terms of how people think about it. I actually saw a report the other day that was done by the UK where they were doing an evaluation of all their companies and what they thought of zero trust is and how important it is to them. And there were some just great stats that popped out to me. One was that 91% of all of their companies said that zero trust was important and that they had some type of plan to adopt it. And then in a follow up question, when it’s like, well, what is zero trust to you? About 49% said that it was essentially a security framework or model, which is vague but accurate, and everything else was basically an incorrect understanding of what zero trust is.

[00:07:28.460] – Sebastian
Is it a VPN replacement tool? Is it a regulatory requirement? It’s a perimeter security product. And it’s like, great. And I understand that this is something that there’s a lot of a kind of nebulous understanding around. But in my mind, where you should focus on zero streaming privilege is just this notion of take away the idea of just giving people more than what they need just to make sure you’re not getting in their way of them doing their job and instead only give them what they need. But make sure you have the tools and systems in place, that it’s done seamlessly, without interrupting and sometimes maybe even making their lives easier and allowing them to do their jobs more easily.

[00:08:13.070] – Ned
Right. It speaks to the dynamic nature of our environments now, as opposed to a more static environment in the past where you had your well defined data center, you had devices that didn’t pop in and out all the time. You had computer accounts that would be a physical server that you’d have for the next 15 years. And yeah, you’d set up the privileges once and that was it. And now you’ve got containers and other ephemeral things that pop in and out. And so we got to make our security approach more dynamic as well. It sounds really good. I like the idea, but I think you and I both know that security can be very difficult to implement, both for reasons that are technical in nature and usually those are not really the hard ones and also human in nature and those are usually the really, really difficult ones. So maybe we’ll start with the technical ones. What are some of the technical hurdles we’ll call them that you need to overcome if you want to implement zero trust and zero standing privilege.

[00:09:23.010] – Sebastian
Absolutely. And I think where you were a great place to start is what you were talking about a little earlier, with this notion of ephemeral infrastructure and the need to incorporate that type of infrastructure, which is becoming a growing percentage of people’s workloads overall and combining that and being able to bridge the gap of that type of cloud based ephemeral infrastructure with your more traditional legacy workloads things like Mainframes or just on prem servers and services that are running, that’s always going to be a challenge. Particularly now as more and more companies are trying to transition to the cloud. So being able to have a system that can accommodate all of these different types of locations, all these different types of basically computing environments that companies rely on these days to actually run their businesses can be very, very challenging. And then you’re also trying to incorporate that into the existing tools and workflows that every company has, whether that’s additional vendors, SaaS vendors that provide different services like threat detection on endpoints or you have your HR systems that are actually doing managing onboarding and offboarding of individuals and you have your identity management.

[00:10:38.000] – Sebastian
Every company has a slew of different pieces of technology that occupy different workflows. And being able to have something that bridges the entire lifecycle of users and infrastructure within the DevOps side of an organization is very challenging. There’s very few times when you can actually turn to a single tool to be that single source of truth.

[00:11:02.770] – Ned
Okay, so easy win in terms of implementation is go with the new. You already have this dynamic environment or you’re building it and you need a tool that can help you manage the security. Hey, we have a tool that does. That awesome. You can just add it to the workflow as you go. What about your legacy environment? Or legacy is kind of a negative word. Your heritage environment.

[00:11:28.430] – Sebastian
I like heritage. I’m going to steal that. That’s good. Like heirloom. How about heirloom? Heirloom. Heirloom workloads? Yeah, absolutely. That challenge presented by having legacy workloads is one that often not only makes it difficult to adopt new tools to solve for the problems you have, but it also makes it challenging to continue your modernization of your infrastructure and your approaches to infrastructure. So this is something that companies face all the time and it’s will matter. Budget, it’s expensive as well as technical expertise. And then it also starts leading into the human side of things where as soon as you start changing the types of infrastructure that people have to use or the ways in which they use it. You start moving their cheese, you’re starting to disrupt their workflows, which not only makes people pretty upset, but it also just reduces their operational efficiency, which no company wants to do.

[00:12:26.610] – Ethan

[00:12:27.870] – Sebastian
What do we call it?

[00:12:28.620] – Ethan
Heritage. Sorry. Heritage Workflows are going to have some challenges there. What about layering in my existing tooling which is near and dear to the hearts of the folks that are listening to this? We got lots and lots of tools that need privileged access. How do they fit into all of this?

[00:12:48.390] – Sebastian
You definitely need a solution which is open enough either with built in first class integrations or with support through APIs and Open architecture that allows people to interlace their existing tooling with that solution. So that is a really important approach. And if you can’t integrate into the existing tooling, if you’re forcing people to either drop or adopt new tooling while trying to implement a zero sending privilege framework, then you’re essentially doing yourself to fail. One of the challenges that we see a lot ends up being the kind of combination between the technical and the human. At its heart, security is a fundamentally human endeavor. The technical is just an implementation detail. So how do you bridge the two? How do you make it easier for people to not change the way they have to actually do things while also be able to do things differently? And the big challenge there is that zero sending privileges and access. This isn’t like Antivirus where you’re just dropping program with somebody’s desktop and yeah, maybe it uses up a few extra CPU cycles, slows them down or locks some files they download, but more or less it’s something that disappears in the background.

[00:14:04.150] – Sebastian
Instead you are talking about something that you’re right in between all of their workloads. Are they going to have to update all of their internal development APIs to then sign every request when it is hitting a database and using a new form of authentication? Is that something they have to write and replace in all their scripts? That’s the kind of stuff that you don’t want to do because you’re just reinforcing the human blockage. Part of the problem?

[00:14:31.910] – Ethan
Well, there’s two sides to that because on the one hand there’s internal code that we got to support. Right? That’s a problem for the organization. They got to sort out how they’re going to deal with that because it’s their own code. But what about well known tools that might be in production that have a well defined, well known API that’s open? Does strong DM integrate with a lot of those tools? Or is that mostly up to the customer to do that integration?

[00:14:55.150] – Sebastian
Absolutely. We are definitely of the view that doing as much work for the customer and automating away as much of their day to day as possible is one of the number one benefits that we want to bring to the table. So making sure that we integrate directly with the most common identity providers, offer provisioning so that people don’t have to worry about the lifecycle of a user, making sure we can connect to the most common secrets vaults and then having a flexible enough structure that we can very easily plug and play. So everything we built essentially is modular. And anytime there is a nail, the top five most popular secrets faults, and every time somebody wants number six, seven or eight, then it’s something that we’re, we’re happy to add for them. Or if they don’t want to wait for us, you know, we want one or two week turnaround, API is open and they can build that integration themselves, but we definitely have an emphasis on building those first class integrations ourselves because at the end of the day, we don’t want our customers doing extra work. We want them to focus on doing their jobs rather than trying to create a new job for themselves that doesn’t actually contribute to what moves their business.

[00:16:06.550] – Ethan
Okay, so we’ve been talking about the technical challenges of trying to deal with zero trust, a zero standing privilege. Let’s move to the human side of things, Sebastian, because here the technical problems. We’re all nerds on this call. We know how to deal with these. We kind of been through a bunch of this kind of work. There’s work, it’s going to be a thing and we’ll get it done. The human side of things not so easy to cope with security initiatives. Azure going to often fail because of a preference for convenience. That’s been the sticking point in a lot of either consulting engagements or organizations I’ve worked for a full time where it’s like, yeah, that’s great, it would make us more secure. Definitely no one’s going through that process or whatever it is that’s going to make us more secure. It ain’t happening. We’re not going to do it. So we’re going to compromise. So walk us through how an organization is going to get their heads around this zero trust. Just backing out to the level of zero trust is hard. The zero standing privilege is to me even harder in the way that you’ve described it because it feels like it’s going to be an inconvenient or difficult thing.

[00:17:12.650] – Sebastian
It definitely can be. And I think that given the most common products you see on the market today, given the historical approach of standard Pam products, if you try and achieve zero sending privileges using those types of legacy technologies that were built, in a world where Windows accounts were the number one most important thing to secure. And you were talking about account checkout and Credential rotation. How do we protect these passwords and how do we protect these credentials and make sure that they’re not being compromised? That type of technology ends up being very difficult to use to implement zero sending permissions and the pains will be surfaced immediately both from the technical as well as organizational. So it really requires kind of a rethinking of what is the goal, what are you trying to accomplish here? And I think if you have the appropriate technology, if you have the appropriate type of access solution, it can actually be easier. Let me start with some of the challenges that we see a lot of companies have first of all, zero trust in general, but very specifically or most definitely zero standing permissions. It’s a type of implementation that has to be centralized.

[00:18:29.980] – Sebastian
It’s a type of effort that has to have buy in from the top down.

[00:18:35.570] – Ethan
So back up a second. You said centralized. First of all, what do you mean by centralized? You mean organizationally. Like everyone’s got to be thinking about this from some policy that’s been created by the SEC Ops team or something or centralizes. In functionally you got to go through a central source of truth, if you will.

[00:18:53.770] – Sebastian
Yeah, that’s a great question. So definitely more on the functional side. I think that you want to leave room for the policy to be decentralized having kind of one policies are have crafted policies for everyone is going to be a non starter. Nobody has that type of organizational visibility, particularly when you get to a certain size. But from a functional level, again, going back to the notion of not moving users cheese, we were talking earlier about technical challenges. A lot of that is more on the administrative, deployment and user perspective. From an organizational perspective, there still is that notion as well where you have maybe one team, they know how they think of access and what their teams need access to and then Team B also has their own notion how they express it might be different though. So the functional unification, it has to be a single pane of glass that allows them both to express their policies in slightly different ways while achieving the same goal. So providing that single window that bridges all of their technology, that bridges all their workflows and allows them to express different policies in slightly different ways while at the end of the day achieving the same goal of just access for their team.

[00:20:09.060] – Sebastian
That is like the kind of the functional goal and it kind of reminds me of customer we had, which probably had my favorite extreme example of the challenges of this type of centralization. And when they first started talking to us, it became clear pretty early on that not only were we were they looking to us to help kind of replace an existing Pam solution, but they had nine different Pam solutions at that company run by nine different teams, each with their own budgets, each with their own organizations. And so you are put in a position where if you’re going to try and convince each one of those teams separately, that ripping out what they’re doing today and just adopting something completely new is the way to go. You’re going to fail. There’s no way that you’re going to be able to have 100% hit rate. And you do want to have, or you do need to have that centralized tool in order to really implement a zero standing permissions framework. So instead, what you want to make sure you can do is, like I said earlier, integrate with what they have that is more difficult to move.

[00:21:19.210] – Sebastian
So maybe you’re not telling them to rip out their entire Pam solutions. Maybe instead you say what is the most difficult part of your entire deployment framework? Most people are going to lean towards their secrets. Where their credentials being stored? How are they being handled? And what vaults are those living in? Great. Leave those alone, leave those in place. You have a legacy Pam provider. Just hold on to the vaulting portion of it and then let’s rip out the most difficult, most painful part. So if you’re running like a privileged session manager in combination with those secrets and that aspect is expensive, nobody in your organization likes doing it. So it would actually be a benefit. Everyone on that team is going to enjoy kind of just knocking out this old privileged session manager that they don’t want to have to keep up and running anymore. And great. Well, lucky for you, strong Damn integrates with all of these secrets vaulting tools. You have all nine of them. We’re already up front there, don’t worry about it. And you can just drop that privilege session part, plug your vaulting right into strong DM and then we’ll handle that on day one.

[00:22:26.900] – Sebastian
So over time, you can create a bridge for them to move away from the old way they did things through a centralized solution and not make it super painful upfront while also still preserving the end user experience.

[00:22:41.410] – Ethan
It feels like a technical answer, but it is actually also a people answer because again, you said you didn’t move their cheese. You’re not taking away from them what they had, but you’re providing that bridge of transition mechanism to get you from where you’re at to where you more ideally would like to be.

[00:23:00.890] – Sebastian
Yeah, absolutely. There’s also, again, this notion which I think is really important that we focus on a lot, that’s really important to us. And it’s the idea of the end user pain and not only trying to avoid friction, but give them some more cheese. You might move their cheese a little bit, but let’s give them more cheese or tastier cheese or new cheese. I don’t know, maybe they like blue cheese, maybe they’re gouda fans like myself, who knows? But if you can make them have a tastier meal, then you make the transition more viable. So the last thing you want people to do, and I see this a lot of time in implementation guides where they say you need to get by and from all your end users. You need to make sure that they’re all advocates for security within the company and that they’re not the only one with privileges being taken away. And that everyone. That sounds terrible to me. That just means that everyone’s miserable. The notion that you’re going to make people feel better by telling them that everyone else is going to be as miserable as them does not seem like a very appealing proposition in my mind.

[00:24:02.240] – Sebastian
So instead, how can you actually make their lives easier? Well, pose something along the lines of you don’t have to go to multiple different areas now to request access to infrastructure. You don’t have to worry about really long delayed turnaround times and your credit approval process is relying on service now or other types of ticketing systems. Instead we’ll have something where it’s just one place, go to it. All of the things that you need to do your job will be just listed in a library. You need access to it, just say so, type in a reason, conduct MFA and boom, you’re in, you’re good. And when you present that idea to users and you’re actually making their lives easier, centralizing the ways that you get access to things, removing the requirement that they have to worry about accounts being provisioned in their name or managing credentials on their side or any of that, just make it disappear. And then all they worry about is what do they need to do to do their jobs and what is the shortest path to it.

[00:25:10.530] – Ethan
You’re talking about how to do some of the sales and marketing within the organization, if you will, to get everyone on board with this idea. So are you underscoring the point that every group needs to have buy in going back to your nine Pam implemented within this organization? Example did all nine groups need to buy in before it was worth trying to implement the zero standing privilege model?

[00:25:33.370] – Sebastian
At the end of the day, no, you can do it piece by piece. But from an organizational perspective, you do want to achieve that. You want to make it easier for people to migrate over time so you just have one place to look. So total visibility is another big concern around these types of organizations. And if you have a world where it’s not a unified platform, then people are going to find ways around it. People are going to find ways to pick like one system versus another. So you want to try and take away all of the old ways to do things and have just one path in a foreseeable, but that’s something that you can get to over time. You don’t have to necessarily do it up front. It does make everything a lot easier, a lot less painful, and a lot more efficient.

[00:26:23.450] – Ned
So much of security practices seem to be if we want to stretch the food metaphor a little bit, it’s about eating your vegetables, right? It’s good for you, but you’re not going to enjoy it. And that’s how it’s awful presented to the end user is your security vegetables. And I think as a parent, I am well aware that you got to sell vegetables a little bit, right? You got to dress them up. You got to make them more enjoyable to consume. And that’s kind of what you’re talking about is, well, yeah, we are improving your security posture, but you don’t really know that you’re just getting a delicious meal at the end of it that just happens to improve your security, but also your user experience. And I think that if you’re going to move people’s cheese, give them better cheese or better give them dessert. I’m just sticking with the food metaphor here. I don’t know why.

[00:27:17.530] – Sebastian
I know. Maybe it’s breakfast just keeping us a little hungry. I’ll provide another metaphor. It’s just one that comes up every once in a while. We have a design principle at Stonegm we call Be the Wand. And the notion behind it is we don’t want to be a product like Facebook or any other type of consumer product where you want to have they’re trying to get your eyeballs engaged as many minutes a day as possible. We want to be invisible, but indispensable. So if you are trying to accomplish something and you know that you can pull out that strong game wand with a quick flip of your wrist, you can do something magical and then you put it away. You don’t have to worry about it again because you know you can turn to it when you need it, but you don’t have to use it all the time. Just imagine, I don’t know, if we’re watching Harry Potter, it seems to have a lot less excitement if Harry is about to cast a spell, pulls out his wand, and first he’s got to configure figure it and pick, okay, well, what length of wand do I want?

[00:28:23.190] – Sebastian
Do I got to get the twelve inch or the six inch?

[00:28:25.180] – Ned

[00:28:25.540] – Sebastian
And then I got to make sure I have the right wrapper on it. It’s got the handle. And then maybe I have to color it or turn it in. And you spend 30 minutes configuring the wand. Nobody wants to do that. There should just be the right way to do it, an opinionated approach that is ideal. And yeah, you want to be flexible. You want to make sure you can accommodate for the unique snowflakes that all have their own kind of twist on what they need to do to actually run their infrastructure and what the infrastructure looks like. At the end of the day, you just want to have something that’s simple, easy to use, and it feels invisible. It feels like you’re just trying to accomplish your goal, and it’s even easier than it was before.

[00:29:09.710] – Ethan
All right, Sebastian, so I think we’ve got a better. Sense of how to deal with the human side of things. It’s never going to be easy, especially for people in It who are really intense and focused and have strong opinions about things. But you’ve given us an idea of how to conquer some of this stuff. So let’s get down into some implementation details. What would the first steps be in writing a zero standing privilege policy? Do we have to focus on perfectly preparing our infrastructure to be able to handle this new paradigm? It kind of gave us a hint that there are some ways to transition in, but give us some clues here.

[00:29:49.660] – Sebastian
Yeah, absolutely. There azure a couple ways. There are many ways to do this. There’s ways that I would recommend more than others. I would start by restating the problem here. And the problem is not trying to think about what is the perfect standing permissions policy, but it’s even more basic than that. It’s what do people actually need to do to do their jobs and how do I figure that out? And there’s two aspects of it. It’s both the human aspect, the account side of things, what does an individual with a certain set of responsibilities actually need to do their job and how can I understand what that is based on historical patterns? And then there’s the infrastructure side, which is, okay, well, what pieces of infrastructure actually fall into those categories that match against that user? And how can I identify them both again on a historical basis as well as on a going forward basis when you’re constantly tearing down and building up new infrastructure? Both of these sides are very difficult. And the historical aspect, if that’s your focus, is probably the most daunting challenge that most organizations face.

[00:31:02.340] – Ethan
Well, it’s that and then it’s also translating all of those semantics into the actual, probably very granular security policy itself. So you’re expressing to the resource what it is that this person is needing.

[00:31:16.730] – Sebastian
Yeah, absolutely. And one thing that we’ve discovered over time is that this is actually a pretty consistent problem across organizations and one in which I don’t think there’s been a great systematic answer to yet to crack this. And it’s this notion of people have a very hard time understanding what infrastructure they actually have and what’s important versus not important. And what does each piece do at a very basic level? We oftentimes hear this request like, I want to know, I want to be able to see very easily who’s accessing my most sensitive infrastructure and what did they do to it? That’s a very common question. We get this is post implementation, but just using the question to demonstrate a challenge that exists even pre implementation. And the natural thought to that is, okay, what is your most sensitive infrastructure? How do you know what that is? And the answer is always generally. And this is a conversation you’re having with the CEO or maybe the head of DevOps. Well, I’m the head of DevOps. I know what the most sensitive infrastructure is. All right, well, does anyone else know? How do you identify it? If you are labeling it or tagging it?

[00:32:27.300] – Sebastian
What is the process when something new comes through? Is there some type of onboarding and ingestion model? What if something changes over time? Can something become sensitive? And there are quantitative ways to evaluate this. Sometimes there are tools that can detect PII in databases, and then you can use that information to label sensitive infrastructure. But that is like a very one off case. And most people have other sensitive infrastructure, which is like, well, this is the code that goes to production. And what if it’s not explicitly the code that goes to production, but it’s a piece of infrastructure that then piece of production uses to build on and then something into production? Is that also considered sensitive? So it’s a very complex question that you’re actually posing to someone where they really just have like, an intuitive answer and that ends up being like, the daunting challenge. Well, how am I even supposed to figure this out? There are two ways you can approach it. You can do an inventory upfront, which honestly, we recommend taking a stab at, but at the end of the day, we find that the best way to really discover this is organically.

[00:33:40.230] – Sebastian
So we have this concept that we are pursuing. The way in which we implement it in the product today versus how we want it to look several months from now is going to be definitely different. But it’s this notion of don’t try to guess. Let policy rate itself based on what people actually end up needing to do to do their jobs. So essentially, you can create this world where you essentially start zero sending privileges. Don’t even try to write the policy. You start with no policy, no privilege, and then let the policies develop themselves based on what people request access to over time. I always like this notion. Any of you are interested in the history of medieval town construction and how they develop over time. But companies in countries like Belgium have, like, great historical medieval towns, and the way they’re constructed is based off of need paths and kind of like localized human demands and what they need to actually live on a day to day basis. Essentially, the towns organically develop based on those clusters of needs and the paths that get drawn between them. And so essentially, you can take the same approach where you introduce a new tool, you introduce pieces of infrastructure, but the same way of accessing it that people always have.

[00:35:02.940] – Sebastian
So people are just going to try to do their jobs on a day to day basis like they always have, and then use those patterns to just accrete a policy based on those behaviors over time.

[00:35:11.910] – Ethan
Well, Sebastian, that sounds like what in networking, how micro segmentation works. When you stand up a micro segmentation solution, you don’t try to figure out what all ports, every server that’s talking to another server, every host talking to another host is going to need, and then write the policy and then press go. You let the micro segmentation solution observe all the communications between the different hosts and then you use that as your baseline because now you’ve observed what was actually needed and now you’ve got your baseline to write your security policy and you can tweak from there. You don’t start from nothing and hope to get it right the first time you watch what’s on the wire on the assumption that there’s too much granularity to be able to figure this out from the get go.

[00:35:56.770] – Sebastian
Yeah, that’s exactly right. I love that analogy. And your end goal here is, again, still not to have the perfect policy, but to have something that covers 80% of the cases and then everything else you allow to. This is when you start incorporating the principles, adjust time access, have workflows that will just make it as easy as possible for that remaining 20% to be filled out over time. So you have the need, you have that core 80% that gets determined by what people actually need to do their jobs and are actually attempting to do, and then the remainder, you allow for this kind of injection of human judgment into the policy itself. So it’s not fully computational, but there’s just a human element that you’re incorporating into it and okay, well, I’ve established this is my policy based on my behaviors, but I need something out of the ordinary. Okay, well, the way to do that is just to make sure you have it as seamless as a workflow impossible in place, so that you can still have a level of friction, which means that not anybody can access anything. But it’s also still pretty seamless and rapid for someone to get to it and it doesn’t impede their operational efficiency.

[00:37:00.860] – Sebastian
And that’s by having a workflow that is like predefined and connects to the resource owner and things azure on Slack or on their phone and SaaS. Hey, Ned really wants to have access to this extra sandbox, even though it’s not part of a standard regime, but he’s working with Ethan on a side project. Great, let’s just do that really quickly. And you just allow them to bridge the gap as seamlessly as possible.

[00:37:26.510] – Ned
You need to have that workflow in place anyway because you may have what seems like a perfect set of policies to begin with, but exceptions come up, people get sick and aren’t able to do their job in that day, but you need to get something done. Oh, well, normally Ethan would perform this task, but today he’s not available and I need to do it. I don’t have privileges, but I can ask you, sebastian, hey, can you elevate my privileges for the next 4 hours so I can accomplish this while Ethan is away and then it just fades out when it’s done. So having that workflow in place is going to be required regardless. Now we have a way to address that 20%. Do you also envision some sort of process to capture those exceptions and make them policy if it is going to be an ongoing thing as opposed to these random one offs?

[00:38:17.950] – Sebastian
Yeah, absolutely. That’s a great point to bring up. And again, I would turn back to integrations with tools that customers are already using to really handle these types of change management and that’s things like being able to integrate with Jira or other change management tools and create paper trails for when exceptions occur so that you can then look back and identify the patterns. Like, all right, well, we see that the people that occupy this role in this team once a month and need access to this resource, suggest a change to the policy or suggest a new policy, get someone to validate it and attach a business logic to it and then you can just add it to the system. So having that dynamic suggestions of how can we change over time based on integrations with change management systems and the paper trails you can generate on that dynamically combines the best of both worlds. You’re still giving that easy access, but then you’re creating also an auditable paper trail that you can reference and then create new dynamic policies down the road. Off. Okay, got you.

[00:39:23.010] – Ethan
Now you’ve described this as being kind of a centralized solution, strong DMs in the middle of all of these transactions. So does that also mean I’ve got one human or one group that’s managing the strong DM solution? So there’s this one person or specialist that is focused on building out policies and getting them deployed and all of that?

[00:39:46.410] – Sebastian
I would say definitely not. Same as I don’t think it’s possible for any one individual in an organization of size to be able to understand how to write the numerous perfect, well crafted, James Mitchener esque policies and writing and beautiful pros to express all the work that people need to do. I just don’t see that as feasible or possible. So in the same vein, you would need to have multiple people actually running the administration. The centralization is the tool itself. So the administration of that tool should still be decentralized to a degree. And you can have oversight and you can build it in a way build that type of oversight in a way that reflects a company’s security objectives. So you can have various levels of powers within the product itself. But again, that’s something you want to keep fairly simple, I think. And instead just make sure you are following the changes itself. One other interesting implementation I’ve seen a customer do actually, is they actually don’t even rely on writing the policies within strong dim themselves. So Strong DM again, we want to give you that opinionated, magical, fairly straightforward way to do it while still being flexible.

[00:40:59.820] – Sebastian
Instead, what they do and it’s just very easy to plug their solution into strong DM and have it kind of take over the policy, writing it in strong DM. Essentially, they write all their policies in GitHub, and then those just get expressed into Strong Dam. So that way you can have the same kind of like merge and revision policies as you would for any type of code, but on your policies themselves, allow those policies to be decentralized. And essentially you’re kind of delegating a bit of that administration outside of Strand Dam itself while still allowing strong DM to handle the most challenging parts, the session management, the credential injection, all the login auditing, but allowing the policies to be written in kind of the native language of the administrators of that company. So it really kind of is a simple way to also be flexible and magical interesting. Yeah.

[00:41:50.180] – Ned
So many products, security products and other products that I see out there that have a policy language require you to learn a DSL, a domain specific language, and there’s a ton of them out there. If you’re going to use OPA we’ve had some here on the show before talking about OPA. And then you got to learn rego if you want to use OPA and other security tools. Maybe they use YAML, but it’s like they have their own verbs and everything in YAML. So with that in mind, are you saying that if I’m using strong DM, I don’t need to learn a DSL? Because that sounds nice.

[00:42:25.070] – Sebastian
Yes, absolutely. The goal of strong GM is to not broaden your vocabulary. That is not what we want to do. We want to stick with some common verbs and nouns and adjectives and just have that be the basic building blocks that can be reorganized, rearranged, and represented in whatever the common language is. We have a TerraForm provider. It’s already built up. We have four SDKs, and we also integrate directly with a lot of these types of other sources of information via those APIs. So it really does make it pretty easy to just rely on, like, a consistent set of nouns. And as long as you have your language that’s preferred, then you can just express it using that common vocabulary that we overlap with. I do not want you to be learning another language with strong DM. That is not something that I care to put on people’s plates.

[00:43:19.550] – Ethan
If I’m implementing zero standing privilege, I want to turn to the user perspective. Sebastian it feels like this can’t possibly be seamless as the end user. There’s got to be some disruption to my life. This is not going to be smooth sailing, I guess. Tell me I’m wrong.

[00:43:36.230] – Sebastian
You’re wrong.

[00:43:38.390] – Ethan
Okay, fair enough. Why am I wrong, Sebastian?

[00:43:42.230] – Sebastian
Well, it really comes down to intent. What are you trying to achieve at any given point in the access workflow. You can intentionally make it difficult, but not really any more so than you would want to do today. Typing in a password to log into my SSO can be seen as a form of friction. Even making sure that my fingers aren’t dirty with cream cheese for my breakfast, that I can actually do a biometric authentication that could be work. There’s always some element of friction that you want to have in a situation. The goal with ZSP, though, is to make it not frictionless, but appropriate friction. I still have yet to find a good word for that, actually, or even like more friction. I keep saying friction full, which sounds like a ridiculous word. In fact, I’m positive it’s not a word, but my brain keeps reaching for it. So whatever that is, it’s the appropriate and consistent level of friction. So what you don’t want to do is, well, I authenticated on my work desk, and I’m authenticated AWS strong DM, and I need to access this resource. Previously, I had to jump through a bunch of hoops.

[00:44:54.050] – Sebastian
I had to go check out some credentials, download them, take the key, and then use it to get into whatever the server is. As long as you’re not that difficult, then it’s a win. And you always want to have at least some friction, whether it’s tell me why you want to access this resource today or right now, and just automate away the rest, automate away the device posture, automate away the behavioral aspects of things, which also can be a part of the conditional authorization here. But you just want to make sure that what the end users actually experience is no more difficult. That’s consistent with the way they’ve always accessed things, and that’s really your goal. And then there are some cases where you can make it even easier for them. So as long AWS it’s intentional, where you’re placing the friction and that it’s consistent with or less, I would say those are the goals. So there are ways to do it in which you can make their lives harder, but at the end of the day, giving them tools to make their lives a little easier is really the objective.

[00:46:04.230] – Ethan
Okay, fair enough.

[00:46:06.790] – Sebastian
All right.

[00:46:07.270] – Ethan
Sebastian so again, fair enough. I think that’s fine. I was wrong, because you can make it seamless as long as it’s an appropriate level of seamlessness. People that have heard this conversation and they want to know more about Strong DM, where would you send them?

[00:46:23.800] – Sebastian
Sebastian I would definitely send them to StrongDM Compacket pushers.

[00:46:29.930] – Ethan
Okay. StrongDM compacket pushers. And also, if you’ve heard this and we’ve mentioned that there’s been some other shows we’ve done with Strong DM, including the topic of zero stranding privilege, episode 172. If you go back in time to episode 172, you can hear the first part of this conversation we had on zeros training privilege and strong DM is also on Twitter at Strong DM and you can find them on the other places. Use the search engine thing and you can find Strong DM very easily. Our thanks to Strong DM for sponsoring day two cloud and feeding our hungry families. Now, if you out there listening, if you ring up Strong DM to find out more, would you please let them know that you heard about them on Day Two Cloud, a part of the Packet Pushers podcast network. Or again, use the landing Packet Pushers and virtual high Fives to you for tuning in. You are a most excellent human. If you have suggestions for future shows, vendors you’d like us to have on topics you want us to discuss, ask us anything. Ned and I monitor our phones every second of the day waiting for you to tweet to us at Day Two Cloud Show.

[00:47:30.740] – Ethan
And if you don’t do Twitter because we get that, you can fill out the request form Day Two Cloud IO. And until then, just remember, cloud is what happens while it is making other plans.

More from this show

Day Two Cloud 180: Understanding AWS EC2 At The Edge

On today's Day Two Cloud podcast, we speak with Jan Hofmeyr, a VP within Amazon Web Services (AWS). This show was recorded at AWS re:Invent 2022 in Las Vegas, and we discuss EC2 at the edge, AWS Outposts and how local zones work, connecting Outposts to...

Episode 178