Welcome to Day Two Cloud! In today’s sponsored episode, strongDM is back. In case you’ve forgotten, strongDM bills themselves as the “Infrastructure Access Platform”–a tool that gives your ops folks secure access they need to the infrastructure they manage no matter where they are, and all without a VPN. You can get as granular with the access as you like, and everything can be logged.
On today’s episode, we’re talking once again with Britt Crawford, Director of Product. Britt’s going to talk through the idea of “zero standing privilege”. Zero standing privilege is an evolution of credentials management. Let’s say you start with the simplest always-on usernames and passwords, move from there to privileged access that provides tighter controls, and then get to just-in-time accounts where credentials don’t live forever.
What’s beyond that? Zero standing privilege. Britt explains the big ideas here, and then we’ll tease out the nerdy details.
We discuss:
- Changing models of access control and credential management
- StrongDM’s definition of zero standing privilege
- Use cases for this approach—widespread or limited to the riskiest/most sensitive systems?
- Attack vectors against zero standing privilege
- Operational implications of the zero standing privilege approach
- What happens if something breaks
- More
Show Links:
@strongdm – strongDM on Twitter
Day Two Cloud 134: Simplifying Infrastructure Access With StrongDM (Sponsored) – Packet Pushers
Day Two Cloud 152: How To Right-Size Access With strongDM (Sponsored) – Packet Pushers
Transcript:
[00:00:09.540] – EthanWelcome to day two. Cloud. And in today’s sponsored episode, StrongDM is back. In case you’ve forgotten, StrongDM builds themselves as the infrastructure access platform, a tool that gives your Ops folks secure access they need to the infrastructure they manage no matter where they are. And all without a VPN. You can get as granular with the access as you like and everything can be logged. Listen to day two cloud episodes 134 and 152. If you want a StrongDM refresher on today’s episode, we are talking once again with Britt Crawford, director of Product at StrongDM. Britt’s going to talk Ned and me through the idea of zerostanding privilege, zero standing. Privilege is an evolution of credentials management. Let’s say you start with the simplest always on usernames and passwords, right? We’ve all done that. You move from there to some sort of privileged access that provides tighter controls, and then you get to just in time accounts where credentials don’t live forever. And well, what’s beyond that? Zerostanding privilege. And I’m going to let Britt explain the big ideas here. And then Ned and I are going to do our usual job of teasing out the nerdy details. [00:01:10.450] – Ethan
Britt. Welcome back to day two. Cloud. And to set this discussion up, Brit, I think you got to walk us through the evolution of the security model that I was hinting at there, starting with the basics of Kubernetes and passwords. So walk us through this evolution. [00:01:24.260] – Britt
Thanks for having me back. Yeah. So at StrongDM, we’ve kind of taken some of the best practice around security and sort of the evolution of that thinking and solidified it into what we call a Secure Access Maturity model. And this model kind of, we hope will serve as a guide for how do you evolve your security practice. And so if you think of the basic thing, oh, I need security, I’m going to put a username and password on my database. [00:01:52.210] – Ned
Right. [00:01:52.620] – Britt
And then I’m going to start thinking about network security. I would say, oh, well, only things from the secure network should be allowed to access the database. This is sort of like the very low level, but when you’re talking about the modern cloudbased world, the first step is actually really realizing that a lot of that old perimeter security doesn’t apply. So you’ve got to start thinking about identity, human identity, machine identity. [00:02:17.620] – Ethan
Well, I mean, it applies, Brit. It just it’s the one small piece of a way bigger puzzle these days. [00:02:24.490] – Britt
Yes, that’s a better way of putting it. It applies and it is necessary, but it is very insufficient. [00:02:30.900] – Ethan
Yeah, for sure. [00:02:33.040] – Britt
So you’ve got to start thinking about identity and how do I verify it as a how do I verify that this machine is supposed to be on this network? How do I verify that this machine is supposed to be on this network and able to talk to this database with a right privilege? And so that’s sort of level one in our framework, which is identity based access. Are you applying identity in every step of your security model? The second level we’ve got is before. [00:02:59.610] – Ethan
You go to the second step, you were hinting at zero trust kind of stuff. It sounds like part of what zero trust is all about. Is that a fair comparison to make? [00:03:08.660] – Britt
That is a fair comparison to make. So, yes, there is no, this is very much back to the BeyondCorp principles in that lovely Google white paper, where there is no place that you can get to within a system or a network that grants trust in and of itself. You are doing capability enforcement at each point in your security models. You’re saying not only is this who I think it is, but do they have the rights to do the thing that they are asking to do? [00:03:38.590] – Ethan
Okay, so before I interrupted you, you were getting to the second step there from the basics, the lower hanging fruit. [00:03:46.460] – Britt
Yes. So the basics is you’ve deployed SSO. You’ve got identity verification at each of your systems. The next step is, okay, you’ve got some actually very juicy targets that are a little different than your normal accounts. And this is where we get into privileged access. And there’s an entire industry privileged access management. And why does this exist as a separate thing from security? And it is basically kind of the fundamental theorem of security. These are your most valuable assets, and so you need to defend them harder because people are going to attack them harder. [00:04:25.160] – Ned
Right? So people are after, say, my domain admin credentials. If I’m thinking in more traditional sense of an active directory, I really shouldn’t be using those domain admin credentials as my daily driver credentials on my laptop, because that’s just a terrible idea. Is that something that would be considered a privileged access account? [00:04:44.520] – Britt
Yes, absolutely. A domain admin Credential, a database Credential, anything that confers elevated rights and that could be used to either exfiltrate data, establish a back door, and permanent access to something, anything like that. And so you hinted at sort of the first level of Pam practice, too, which is like, oh yeah, I shouldn’t be using that as my daily drive Credential. And in fact, probably you shouldn’t be having that Credential in your possession all the time. You should need to maybe check it out of a vault and use it for the duration of your administrative session and then check it back in. And this is sort of where Pam came from, but there is kind of a further evolution on that because even if you think about checking credentials out of a vault, so you’ve got Hash core vault, you got cyber, you’ve got something like that. And you say, give me the admin Credential for the SQL Server database host, right? You check it out, you enter it in, you put it back in. Boom. Why have I got that Credential on your machine in the first place. [00:06:01.910] – Ned
Right? Because if my machine gets compromised in any way and there’s a trace of that Credential, or if my machine was already compromised and I check that Credential out, boom, someone’s got that Credential and they can just start using it. And I might have to deserve that for a while. [00:06:16.590] – Britt
Yeah, that’s absolutely right. If your machine was already compromised, it’s really the nightmare scenario. Somebody that you’ve got some sort of malware sitting on there that’s just waiting and it looks for that session and snipes the password and sends it off. And we can thank cryptocurrency for this. Like attackers have gotten much better at exploiting much smaller access windows because of cryptocurrency accounts. Everyone has MFA. You’ve got to snipe that MFA code so that you can get in. [00:06:49.840] – Ned
Right. It reminds me of microsoft had this best practice they were pushing for a while where you’d have a privileged Access Workstation and you would only do these privileged activities from that workstation, but then that made that workstation a really juicy target because it has all of the credentials on it. [00:07:08.890] – Britt
Yeah. And often what you’ll see is a combination of that pattern where you have a vault and then you have a Privilege access Workstation, which is usually a virtual desktop instance in the cloud. And you have to go to that so that you have an extra cutout between the end user machine and the privileged machine. They don’t connect directly. [00:07:30.490] – Ethan
Kind of related. I definitely don’t have a code running Python scripts with access tokens embedded in environment variables. That’s certainly not a thing I’ve done at all. Nope. [00:07:40.390] – Britt
No, not at all. You certainly wouldn’t even deploy that into your cloud instance. Right? [00:07:47.370] – Ethan
Obviously. Definitely didn’t do that. No. [00:07:51.110] – Britt
No. There are actually better ways to do that now with Parameter store, but you still have that Credential floating out there and if somebody gets into that box, they can pull it right out of memory and use it. And so this is actually something we’ve invested a lot in at StrongDM, is we remove every single Credential from the end user box and often, even in the case of that cloud instance, from the box that’s running that Python script. How we do this is by we have our own secrets fault, but we also integrate with all of the major secrets faults, AWS, Secrets Manager, HashiCorp Vault, all of those guys. And StrongDM speaks directly to the Vault and injects the Credential on the wire so you as an end user never see it. And not only that, only the last mile node in the StrongDM network ever has access to the Credential. [00:08:59.740] – Ned
Got you. So if I from my desktop, I’m requesting access to a thing that goes through the StrongDM network of nodes, the mesh of nodes and linode that is closest to the resource I’m trying to access. That’s the one that actually pulls the Credential and uses it on my behalf. But I never see it backwards all the way through that mesh to my desktop. [00:09:21.300] – Britt
That’s correct. You never see it. It’s never stored on that linode. It’s resident in memory for the moment that it takes to inject it on the wire and then it’s thrown away. [00:09:31.310] – Ethan
We haven’t arrived at zero standing privilege, though. Are we still in the middle of the security model evolution? Brett? [00:09:37.120] – Britt
Yes, we’re still at the privileged access level. Right after that, there’s two more. There’s Justintime access and zero standing privilege. And they’re really similar. So just in time access is actually, if your organization gets to this level, you’re doing pretty good. And this is you take away most access and especially privileged access, and you have an easy way to grant it on demand and for a limited time. [00:10:07.160] – Ethan
There’S a lifecycle management for that Credential. It’s very brief. You need it, that access is granted and then you use it. And then that access is removed once again. [00:10:16.770] – Britt
Yes, exactly. So these are database administration example. You want to administer the SQL Server. You request access and you provide a reason that’s then sent over to Ned. Ned looks at the reasons, okay, this is good. I’m going to give you access for 2 hours. You’re approved, that whole sequence is audited. And then you’re granted access. You go in, you do your work, you relinquish it. And so obviously the reason this wasn’t a more common practice is that’s a lot of coordination of systems used to be a lot harder, takes a lot of work to set up. And so that’s something that’s from the end that we’ve invested in, is making that very simple. So we have, for instance, a slack bot that you can run with StrongDM that you can set up what someone’s allowed to request access to, and then under what conditions is that access granted? If it’s a lowlevel environment, you can say, oh, just every time they request it, give them an hour automatically, but audit that request so that I know what’s happening. And if it’s a high level environment. [00:11:30.150] – Ethan
You can tell the slack bot what policy you want it to apply to incoming requests, or the Slack bot just a proxy that dumps the request into a channel and a human has to respond. [00:11:39.560] – Britt
You can tell it what policy you want to apply. [00:11:41.950] – Ethan
Got you. [00:11:42.550] – Britt
So you can encode your approval policy. [00:11:45.790] – Ned
Okay. [00:11:46.660] – Britt
And so that’s just in time access and the zero standard privilege sounds a lot like that. The difference is that with just in time access, you’re relying on policies and credentials that have been established beforehand and you’re granting access, whereas with zero standing privilege, you are actually in the moment of the request, creating the policy or the access, and then when the session is done, revoking the access. So imagine if you had no account on the machine, you want to SSH in says, okay, I’ve provisioned a user, and then when your SSH session is done, we deprovision these. [00:12:28.390] – Ethan
So that implies if I don’t have a pre existing policy that tells me how it would govern a particular request, I’m making it up as I go that the policy applied to a request will change depending on the context of that request. [00:12:45.040] – Britt
No. You do have to consider what sorts of things can be requested, under what conditions can they be approved, what level of access you’re going to grant. You have to think about this stuff ahead of time. And so sorry, I’m using policy. Policy is one of those overloaded words that we get a lot where I’m thinking about actual things, like I am policy versus company policy about who should have access to the database. [00:13:12.150] – Ethan
Okay, got you. [00:13:15.640] – Ned
Yeah. [00:13:16.030] – Britt
So there’s the actual security policy implementation, and then there’s the company level, who should have access to what policy. [00:13:26.510] – Ned
Okay, so I’m struggling a little bit with the differentiation between zero standing privileges and just in time access. So is the idea in just in time that there’s an account that already exists on the remote system? I’m just generating credentials based off of that account, and zero standing doesn’t have that. Is that the main difference between the two levels? [00:13:50.760] – Britt
Yes. You’re effectively provisioning and deprovisioning the access rights in the moment with zero standing. It’s basically the philosophy that no access is safer than no access. Right. You can’t get to anything by default, then that’s your safest posture. And so it does require a lot of coordination and automation to say, oh, in this moment, I can create an iam policy, or maybe I have a preexisting role, and I’m going to now attach the right to assign that role to a particular user. [00:14:33.410] – Ned
Got you. Okay. And what’s really interesting to me about that is each new Credential and accounts and everything that’s generated dynamically, that’s a single thing that you can audit against. So if I want to know not only what you did, but what you did at this specific time when you requested this Credential, I have a whole through line for that, and I can really see what you did with that Credential and track it back and then also see if somebody tried to use that Credential later. [00:15:04.390] – Britt
Yes. And when they use it later, it should generate a failure event that you can then investigate. [00:15:13.310] – Ned
Right. So if I’m worried that your box is comp well, I know your credentials aren’t supposed to hit your box, but if I’m worried that a box is compromised somewhere and I’m looking for a Credential replay, that’s something that I can audit for. And if it happens within ten minutes of the access being revoked okay. There’s definitely something going on. There’s a bot or something somewhere that tells me I’ve got a compromised system that I have to take care of. [00:15:39.640] – Britt
Yes. I mean, most likely it’s somebody wrote a script and they tried to reuse the Credential. [00:15:46.390] – Ned
Well, they shouldn’t do that either. [00:15:49.390] – Ethan
So Brett, who is the company that wants to take advantage of a security scheme like this because it feels heavy. So is this like I’m a company where I really care about risk and I got to mitigate all the risk possible so I’m going to go this route or is it more for everybody? [00:16:08.210] – Britt
I think it’s more for everybody. As strong Em allows you to better take advantage of this and as strong YM evolves and tools evolve, I think this is going to become the strategy for everyone. Because there’s the problem of not just I’m very risk averse or I have very valuable targets to go after. There’s also the problem of I am a very large company and I have a giant AWS account with thousands of people using it. How do I manage that? How do I possibly know what’s going on in that account if I’m trying to set up a fabric of standing permissions, right? How can I know how all these I am policies interact? How can I know? And there azure some tools that will help you analyze that but ultimately there’s a human understanding problem of not being able to say what your security posture is. How effectively am I defending this? I don’t know because there are 47 policies, they all interact and I can’t figure out what the actual end result of whether this should be approved or not. [00:17:13.990] – Ethan
So you’ve got to explain how StrongDM is going to make this easier for them. Because the reason a lot of times these more complex schemes go is exactly what you were saying. The policy matrix is so complicated trying to get people in the right groups and given the right thing, it’s too much trouble and you end up over permitting giving people more than they really need just so that they get out of your face and can get their job done. So this sounds even more complex than that, what you’re describing. But you’re telling me it’s easier. [00:17:41.740] – Britt
I am telling you it’s easier because what StrongDM does is we stitch together a lot of pieces of that matrix and also we extend the capability to easily grant and revoke timebased access to systems where it would be difficult like redis cluster or a database or something that is not already integrated with a modern security framework. So we provide a single point of enforcement, a single place to view what all that access is and a simple way of automating both the distribution of access so the grant of that zero standard privilege but then also the provisioning of the Credential. Using that vault integration we can dynamically provision that Credential and revoke it. [00:18:38.960] – Ned
So with all these additional protections in place, I mean, you kind of mentioned before attackers are looking for just the smallest little thing that they can get in from. How would an attacker look at zero standing privileges and still see a way to infiltrate? [00:18:58.540] – Britt
That’s a really good question. I mean, the obvious and kind of cheating answer is social engineering. But. [00:19:12.340] – Ethan
It’S a trade off, right? Because on the one hand we’ve cut off, there is no standing permission that can be attempted to be compromised. That doesn’t exist. Now you’re coming hat in hand every time you want to access a resource to have the permission, the policy built for you, when that access granted to you so you can go manage the thing. So that becomes a much more difficult target to attack. So in my mind, if I’m the attacker, I’m going to I guess I’m looking at the StrongDM tool and going, that’s the thing I want to attack in some way. Is that right? [00:19:48.710] – Britt
You could try to attack the StrongDM tool. You could go directly at it. An end user workstation. Might be easier to try to get to and try to compromise an end user. You might do something exotic like fly a drone with a WiFi bridge up next to somebody’s office. That happened to the big financial firm. They flew a drone next to the office window with a WiFi Pineapple, hacked the corporate WiFi, hacked an end user workstation and then got in to steal the financial data. [00:20:25.610] – Ethan
That’s even better than a Mr. Robot plot. Outstanding. [00:20:28.630] – Britt
I love it. It’s really good. And it really had trying to remember the name, who it was. I read it in Krebs on security and they didn’t disclose the name of a major Fortune 100 financial firm. [00:20:46.240] – Ned
That’s a little scary a question that. [00:20:50.460] – Britt
I should check the details on that one. If I need to go back and say rerecord who it was because I’m pulling that one out of memory. The Wi Fi Pineapple attack is real, but I don’t remember who it was. It was a big retail trading. [00:21:04.760] – Ned
I like it being mysterious. Yeah. A question that I always think of when it comes to setting up this sort of environment is we like the idea of zero trust and affirming and authenticating through all the steps. But there needs to be a system that is able to provision these credentials and that system needs to have a credential of its own to do the provisioning of the credentials, which gets back to this idea of secret zero. So how do you secure that system that’s doing the provisioning of credentials? [00:21:46.240] – Britt
There are a couple of approaches that you can do that kind of like sidestep the secret zero problem. So if you think about it as an administrative privilege and it’s doing rights to the policy layer and things like that, that becomes a very valuable secret to steal. And that’s a difficult approach. But instead you do a little jujitsu and use, say, the cloud providers role assumption model or authentication model and say, what I’m going to do is I’m going to put a gap in here and say, I authenticate to my SSO and I’m using a tool like StrongDM. I then access the cloud and then the component of StrongDM that’s running inside my account. That is the thing that actually has access to do account provisioning. And it’s done by say, im policy. I don’t have a tool that’s going in there and provisioning any provisioning access. What I have is I have a tool that’s allowed to I have a piece of software that’s sitting in there. It’s identified by the cloud provider itself and it’s allowed to assume different privilege roles. [00:22:57.940] – Ethan
All right, Brad, let’s say we figured out the secret zero problem one way or the other. So we’ve got a robust secure infrastructure platform upon which we can now begin handing out our credentials using this zero standing privilege model. All right, there’s a human involved here at some point, so walk me through how to set up access to a resource we want to manage using zero standing privilege. [00:23:24.940] – Britt
It’s really not that different than setting it up through any other access model. The additional layer is actually defining who should be able to request access and what level of privilege should they get. Everything else is mostly going to be the same. You’re going to register the resource, say, here’s what it is, here’s how we provide access. And then you’re going to say either I’m using something like Vault to issue dynamic credentials so they would dynamically provision deep provision account, or I’m using something like AWS IAM to do role assumption have a similar interaction. But the real new layer is, should Ethan be allowed to request write access to that instance and under what condition should that be approved? And so that is where you have to put some thought in and the. [00:24:21.600] – Ethan
Conditions can be complex. It could include security posture of the end point, I think, right, it could. [00:24:30.410] – Britt
And generally so again, you run into a complexity problem where it’s like, how do I understand what my security posture actually is? Right? How do I understand what my policy is? And so often I think you want to have handled that security posture beforehand. But for very where you say like, oh, you can’t even authenticate unless you Azure on a known device with the hardware token that was issued to you by corporate it right. In some cases, though, you are going to want to be able to define those sorts of conditional access rules. I think that’s really the Holy Grail, and there are a lot of people trying to implement that, but there’s not one tool that’s going to let you do that throughout your whole infrastructure yet. And so you might want to say, oh, this is a production database. To access a production database, it has to be during working hours, it has to be on a corporate laptop. You have to authenticate with your hardware token and from an IP that I recognize or from an IP that is in your normal area of operation. [00:25:43.910] – Ethan
And again, as you say, it’s not that much different because in fact, what’s happening is a subtle difference. We are building policies on the back end of whatever the resources were accessing on the fly. So it’s not just credentials being created dynamically, it’s also policy being created dynamically. That’s the subtle distinction here. So from an Ops perspective, if I’m managing the StrongDM platform, it doesn’t really feel that much different to me. Now, is this a feature box I’m checking or something to enable this functionality? [00:26:16.910] – Britt
No, this is more a series of practices and things you’re setting up. So you’ve configured your Vault, you’ve configured how you want resources to access credentials from that Vault. You’ve configured your SSO integration and your device posture management for that integration. You’ve configured within StrongDM. What are your rules for approving this access? Under what condition should it be granted? What’s the grant period? All of those sorts of things. [00:26:56.060] – Ethan
What you’re highlighting is a security model that I am unable to build on the StrongDM platform. [00:27:03.340] – Britt
Correct? [00:27:04.840] – Ethan
Okay. Does it feel any different from the user perspective? If I’m the person who’s trying to authenticate there’s a strong BMC client, as I recall, and I’m leveraging that to access my resource, do I see or feel any different? [00:27:22.840] – Britt
No, you don’t feel any different. You’re going to go, you go, you make your access request. Once it’s approved and granted, that pops up in the String client and it says here you have access to the next 3 hours. You go, you access it. When you’re done, you go back, you can relinquish access and it’s immediately revoked. [00:27:40.540] – Ned
Right? You don’t have to refresh a credentials cache or anything that you have stored locally because you’re not getting the credentials. You’re using the client and it’s proxying that connection correct for you and injecting the credentials somewhere along that path. [00:27:54.790] – Britt
So it fits into the end user workflow just like everything else. There’s no change other than making the request. [00:28:05.290] – Ned
Got you. [00:28:07.390] – Ethan
It’s the client that makes this Credential injection magic happen somehow or another, isn’t it? Or that facilitates it. Because that’s a detail that’s been bugging me since you mentioned in the beginning. Yeah, we inject it like it’s the easiest thing in the world. Like why the heck you do that? Well, if the client yeah, actually, just walk us through that, Brit. How that happens now that we’ve been reminded that there’s a client component, walk us through the steps along the way and how that Credential injection component happens. [00:28:35.140] – Britt
It is the client that really makes the magic happen there. And it is so the client presents support on your local machine that you can speak to, that will speak the language of whatever the end service you’re talking to. Is. It’s postgres? It speaks the postgres protocol http SSH whatever. Right, so you talk to that. And the great thing about it is you can give it no credentials, you can give it whatever you want. It will always say yes. And that traffic is then forwarded along the StrongDM software defined network, goes through an encrypted tunnel to the end destination. And at that point, the last mile node in the StrongDM network is deconstructing that traffic and modifying it to inject the Credential. [00:29:27.710] – Ethan
Well, the last mile, you mean the StrongDM inbox that’s effectively proxying my connectivity to the resource I’m trying to manage? [00:29:34.760] – Britt
Yes. So depending on your network topology, you may have to go through several hops, but you connect into the strong Em network. And from your point of view as an end user, it’s like a wormhole, right? You don’t see any intervening network. If you’re an It team, you don’t have to worry about the intervening network. It’s all layer seven. It sits on top of the actual IP networking. But then that traffic is delivered to a node that sits very close to whatever targets you’re trying to access. And that’s the node that is both going to do Credential injection as well as session recording. [00:30:14.590] – Ethan
Because now we’re at the place close to the resource we’re trying to manage where, okay, we need to hand off credentials to the thing that’s going to actually say, okay, you can come in the door. How are we doing that? It doesn’t have any idea that there’s all the StrongDM back there. It cares about whatever the credentials are that you’re presenting to it in the protocol and manner in which it expects it. [00:30:32.740] – Britt
That’s correct. And so that thing is going to speak directly to your vault, get the Credential inject it into the authentication headers just like or handshake, just like it normally would, and then you’re off. And depending on how you’ve set that up, that connection itself is also encrypted. Right? Because you’ve configured a database to use TLS. And so the strong Em node in the database are speaking TLS inside your network. [00:31:04.390] – Ethan
Another detail you could clarify for me about the architecture. You’re talking about a wormhole and the StrongDM software defined network. And it sounds like what’s happening here? I thought I was, I had like a StrongDM server that was running on prem in one of my data centers or up in AWS or something like that. And from what you’re describing, it sounds more like is there some central StrongDM mesh of servers that you guys are providing for me? [00:31:32.510] – Britt
No. So that’s another place where actually we made a conscious decision, both so that customers can control their own data and for security reasons, there is a centralized brain to strong Em that we run, but the actual data connection is entirely run by you. And so you have nodes that can be easily deployed within your account that provide connectivity into your infrastructure. And so we’re actually never handling your traffic. [00:32:05.510] – Ethan
So. SaaS nodes that I’m spinning up on demand supplied by you. Or I’m like standing up a container or VM or something. [00:32:15.790] – Britt
A container, a VM, however you want to run it. But yes, you’re standing up an instance. [00:32:22.390] – Ethan
Got it. [00:32:24.640] – Britt
And we’ve built those to be as easy as possible to deploy. You just turn them on. You make sure that you have nodes that can talk to all the target resources that you want to talk to, and then some that can accept traffic from the outside world. And they will discover the interconnections between them and routing and also provide ha and failover. [00:32:51.190] – Ned
Okay. So speaking of failure and potential failure modes, is there like a break glass sort of situation? Like I’ve lost access through StrongDM where I’ve lost access to this zero standing privileges provisioning process. But I really need to get into the thing. How would I as an ops person go around setting up that brake glass in case of emergency scenario? [00:33:19.990] – Britt
You’ve always got that problem. And the best way to solve it generally is to deploy a break last either VPN or some other or zero trust networking solution that you can turn on. Should StrongDM, should you lose access to StrongDM, it’s very similar to what do you do if October goes down? Right? You need another Credential to get into that machine. And maybe you only need one and then you keep it in a nice vault that no one can get to. But you do need some other way. [00:33:53.490] – Ned
It reminds me of this. This is something that happened with Azure Active Directory, is not Azure Active Directory, but the MFA component of Azure ad went down for a few hours. And so people whose tokens were up were trying to authenticate to Office 365 and they couldn’t. And that included administrators. They couldn’t even get in to turn off MFA for their users so that their users could keep getting their work done. And if you didn’t have that one account that was set up to not use MFA and was an admin or whatever, you were just kind of in the water until MFA services were restored. So like I always think of that scenario when I’m like, I need a break glass set up just in case that sort of thing happens. [00:34:42.710] – Britt
There are really two break glass scenarios we think about. So there’s one is StrongDM network goes down. Either there’s a major internet outage, somebody cuts the fiber to all of the regions that we’re running in and the extremism control plane goes down. The brains of the system goes down. That’s going to be one where you have to deploy a secondary networking technology to get in the infrastructure. But then there’s the other one, which is your SSO goes down or a particular node goes down. And there we do provide break glass administrator accounts so you can configure alternative authentication mechanisms so that you can get in and rewire things. [00:35:31.760] – Ned
Got you. And of course, obviously all that would be heavily audited. You’d want to sign the whole time. [00:35:39.640] – Ethan
This goes back to our early discussion about points of interest for attackers. As you deploy an infrastructure like this, the back door, the break glass in case of that could be something that they’re going to assume might be there and see if they can figure out what it is and start poking at it. [00:35:54.860] – Britt
It is, and it’s really the protection there is the discipline of not using that as your daily drive of keeping that, you know, not on your machine, keeping those credentials, not on your machine in a vault. Like, we’ve had customers who have certificate authentication infrastructure that we integrate into. And so we need one of their Certs to authenticate there. And so in order to get that Cert issued, they have a literal physical safe. You have to go in, you pull the flash drive out of the safe, you get the key. You generate the Cert that descends from the key, and then you put it back in. A digital equivalent of that procedure is what you need. [00:36:44.740] – Ned
Right, exactly. Now, if I’m an auditor and I’m interacting in a zero standing privileges environment, I might get a little flustered, a little frustrated, because I’m seeing all these accounts get generated and deleted, and I need to link those back to actual people making requests. So if I’m an auditor, what am I seeing in the logging? And how can I sort of piece this morass together into something that makes sense to me? [00:37:12.870] – Britt
So that’s another place where StrongDM helps. So often you talk about, like, the three A’s authentication, authorization, and accounting. In the modern world, it’s really four. You need auditing there too. You need to know what everyone’s done. So not only is everything you do within StrongDM, everything you do to StrongDM as an administrator and everything you do within StrongDM as a user is audited, but that is all tied together, and you can easily produce that evidence for auditors. You can say, this is our one source of truth. This is our one source of truth. I can look up every session that Ned ran on Tuesday. I can look up every session that was run against the production database between 137 and 245 during the period of the incident. [00:38:13.090] – Ned
So there’s different ways you can slice and dice it depending on what you. [00:38:17.660] – Britt
And we also provide really simple ways to export that data into your siem system because that’s generally going to be the locus of where you’re performing a lot of that interrogation, because While StrongDM is providing who, when, and what they did. There’s also just tons of other systems that you’re using in your security stack. Right? You’ve got the actual host security reporting. You’ve got logs directly from the target machine that you may want to also join into that data set. [00:38:58.610] – Ned
Okay, so once it exports to the SIM, it still keeps all those linkages between who requested, what they requested against and that kind of stuff. You can get that all back to you. Okay, very cool. [00:39:10.380] – Ethan
And with that question of auditing out of the way, Brett, I think it’s probably a good place to stop. Man it’s a good place to stop. So if people want to find out more about StrongDM, about zero standing privilege, where should they go? [00:39:24.640] – Britt
Strongdm.com PacketPushers all one word is the best place to go. [00:39:30.130] – Ethan
Strongdm.com packet pushers. And the resources will be there for you. StrongDM also has a blog, it’s tech and nerdy engineering kind of stuff. They’re on Twitter at StrongDM. And if you wanted to hear the earlier shows about StrongDM in this series, day Two Cloud, episodes 134 and 152 are where you want to go, and Virtual Highfives to you, you awesome human for listening to the end of the sponsored episode. If you do ring up StrongDM to do an Eval, make sure to let them know that you heard about them on day Two Cloud, which is part of the Packet Pushers podcast network. If you have suggestions for future shows, we would love to hear those. You can hit Ned and I up on Twitter. We both monitor at day Two Cloud Show or fill out the request form on multicloud IO. And if you like engineering oriented shows like this one, and I know you do, visit PacketPushers. Net, subscribe all of our podcasts, newsletters and websites are there, nerdy content designed for your professional career development. And until then, just remember, Cloud is what happens while it is making other plans.
Podcast: Play in new window | Download
