Simplifying FedRAMP Compliance with Teleport

FedRAMP compliance is notoriously challenging, but it doesn't have to derail your DevOps flow or tech stack. Discover how Teleport’s robust infrastructure access and security platform addresses some of the toughest questions and hurdles in the FedRAMP process, empowering engineering, compliance, and security leaders to implement and enforce security controls seamlessly.

De-Risk and Accelerate Your FedRAMP Path: Learn how Teleport can significantly mitigate risks and speed up your FedRAMP compliance process.

Live Demonstrations: See firsthand how Teleport’s capabilities enable your teams to meet FedRAMP compliance requirements with real-world examples and "with" and "without" workflows.

Auditor-Friendly Solutions: Understand why auditors love Teleport and how it simplifies the auditing process.

Practical Strategies: Whether you're just starting your FedRAMP journey or looking to enhance your ATO’d product, gain actionable insights into addressing FIPS requirements, access controls, auditing, and more.


This webinar is perfect for engineering, compliance, and security leaders who want to reduce the burden of FedRAMP compliance while keeping their teams focused on innovation and market delivery.

Don't miss this opportunity to learn how Teleport can streamline your FedRAMP compliance and make your life easier.

Key topics on Simplifying FedRAMP Compliance with Teleport

Teleport is a centralized solution for managing access to infrastructure resources, addressing many FedRAMP compliance requirements in one place.

The webinar covers five key FedRAMP compliance questions and shows how Teleport addresses them:

How are access controls applied to hosts?

Are there any shared or break-glass passwords?

How do you implement concurrent session control, timeouts, login banners, etc.?

Teleport integrates with identity providers like Okta for centralized user management and access control across different infrastructure resources.

Teleport supports FIPS mode with a simple command line flag, simplifying compliance with cryptographic requirements.

Teleport eliminates the need for shared passwords and break-glass accounts by using short-lived certificates for authentication.

Teleport provides built-in features for concurrent session control, timeouts, login banners, and other FedRAMP-specific requirements.

Comprehensive audit logging and session recording are available through Teleport, addressing FedRAMP's logging requirements.

Teleport can significantly reduce the timeline for implementing centralized access control compared to building a custom solution.

Teleport runs inside the organization's boundary and does not require its own FedRAMP certification when used for FedRAMP compliance.

Teleport logs can be exported to a SIEM for real-time security alerting and analysis.

While Teleport itself is not FedRAMP authorized, it is designed to help organizations meet FedRAMP requirements within their own environments.

Expanding your knowledge on Simplifying FedRAMP Compliance with Teleport

Transcript - Simplifying FedRAMP Compliance with Teleport

George: Xin, are you able to hear me okay?

Xin: All right, folks. We'll just give it another 30 seconds for folks to join.

Xin: All right, it's about a minute past the start. So why don't we get started? Hi folks, thanks for joining us today. In today's webinar, we'll be discussing how you can simplify FedRAMP compliance with Teleport. My name is Xin. I'm the VP of Product here at Teleport. Joining me today is my co-host, George. George, do you want to take a minute to introduce yourself?

George: Yeah, sure. Thanks, Xin. So George Chamales, independent advisor to companies that are working on all sorts of different technologies, lately been focusing on FedRAMP.

Xin: Cool, thanks, George. And before we dive into the content of today's webinar, we'd love to take a little bit of time here to learn about who you are and where you are in your FedRAMP journey. Lexi, can you pull up the quick two-question poll, please?

Xin: All right, let's give it another minute for this one, and then we'll move on to our next one.

Xin: All right. Let's give it 30 seconds here before we move on.

Xin: Cool. So I think we have a lot of folks sort of thinking about starting their FedRAMP journey and then a couple of folks kind of in progress or have already have an ATO in place. Great. Good to know. Thanks guys for participating. And George, take it away.

George: All right. Thanks a lot, Xin. So hello, everyone. Thanks for taking the time today. We're here to talk about FedRAMP, which in the world of public security compliance is the hard one. There's thousands of controls, individual requirements, which make it really difficult for a lot of teams to get through, and it tends to occupy the far upper right corner of the compliance pain and complexity scale. And I've spent the last two decades working at the intersection of engineering and security. For the last several years, I've been entirely focused on working through FedRAMP. I've built one large program from scratch through to ATO. I've advised on a dozen more teams working at various stages, from startups to SCRs, to recertification, and lately working with the Rev5 Uplift. Now, I've known the Teleport crew for a while now. We're all based here in Oakland. And when Xin and Diana asked if I'd work with them on a presentation about Teleport and FedRAMP, I agreed because in my personal and professional opinion, if you're not using Teleport for FedRAMP, you're probably doing it wrong. Xin, can we move forward on the slides? Yeah. Okay. Next one, please. There we go. And one more over.


George: So when I say you're doing it wrong, I mean this in like the figurative glib version — like there's got to be a better way than what we see people doing out there in ad hoc solutions to try to meet these requirements. And I also mean it in the very literal sense. So on the next slide here, we have the list of controls that apply to backend admin access. And it's important to point out that it's way more than just the access control family. If you're not using a centralized solution that's specifically tailored to FedRAMP, then the chances are really good that somewhere in your infrastructure, you're either violating one or more of these compliance requirements, or you're doing something that's legitimately insecure, or most likely both. Now, of the range of options that are out there, so far, Teleport's the only one on the market that I've come across that both meets the FedRAMP requirements that we need to be able to make it through ATO to meet the controls and also implements the sort of security that you want when you're operating any sort of online infrastructure. If anybody knows anything better, please let me know. For today, we're going to frame the discussion around five key questions that come up in the course of a FedRAMP audit.


George: All right, so we've got these five questions: how are access controls applied to hosts? How do you use FIPS for admin access? Are there any shared or break glass passwords? How do you implement concurrent session control, timeouts, all these finicky requirements per session? And what audit logs do you have? What makes these specific questions hard is that they lie at the intersection of very important to the US government and your US government customers, they're hard to implement and they're really easy for auditors to check. So in going through FedRAMP, in maintaining FedRAMP compliance, you have to get these right in order to come through your audits and to provide effective security for your customers. So what we'll do as we go through here is we'll talk through these questions. I'll give the brutally honest answer of how someone would respond to these questions without using Teleport. And then we'll hand over to Xin and he'll give you what it's like to use this, to go through this with Teleport. So let's start with the first question. How are access controls applied?


How are Access Controls applied to internal hosts?

George: Now, without Teleport in a large-scale infrastructure, there's going to be a variety of teams. In the absence of a centralized solution, there's going to be a half dozen different ways that folks have come up with to access their technologies. And those approaches are going to be different depending on what technology is being accessed. We'll see things like a VPN at the perimeter and it'll be wired into an IDP. Then we deploy jump boxes inside so that the engineers can use them to get access to internal hosts. Then you've got to build custom key management systems to push SSH keys out using something like Ansible. And then you have to keep those keys inside the boundary and have a periodic process to rotate them and manually remove them whenever people leave the team. And then we've also got databases, which we use from the jump boxes, but to get access to those databases, we have to pull a shared password out of somewhere in secret storage. And then there's Kubernetes, which people will have various ways to get access to through something like kubectl or IAM roles associated with the jump boxes. And then maybe they'll have locally stored passwords there. And all of this will have to be integrated with IDPs wherever we can, except for those services that can't integrate with the IDP because enabling FIPS mode breaks single sign-on. That's a lot to say. And one of the consistent issues in going through audits is that the more you talk, the bigger the chance that you're going to have trouble. So Xin, same question, but with Teleport, how is access control applied?

Xin: Yeah, absolutely. Let's jump to Teleport and take a look. So I have this Teleport. Let's just go through a typical workflow of how a user might access infrastructure resources through Teleport. And we try to meet as a product, right? We try to meet users where they already are. So that's why we support authentication through various different SSO providers, whether that be Okta, which we're using today, OneLogin, Ping Identity, or any other SAML or IDC providers. So as I said, for today's demo, we've configured this particular Teleport cluster through Okta. So we're going to go ahead and log in. Let me pull that. So basically we click here, we go through the Okta login process. It's challenging us for multi-factor. One second. And we're in. All right, so we've logged in as this account here, and the first thing that this account sees when it logs in is an overview of infrastructure resources they have access to. So here we see that this account has access to AWS, to a Windows server, to Postgres database, to Kubernetes cluster, a Grafana instance, and also a Linux server.

Xin: So say we want to SSH into the Linux server to do some debugging. All we have to do is click Login, select the Linux login that you want here. So let's just say we want the Debian one. We're now connected. Who am I? We can do all of this stuff as you typically would. And that's pretty much it. And then let's say we want to now launch an application through Teleport. All we have to do is, again, take this Grafana instance example, press Launch, and now it does all the redirecting back, and we're authenticated as the user in this particular instance. So we're logged in as this user to Grafana, and we can do whatever we need to do with regards to telemetry here. So the key takeaway here is that admins can easily and securely manage all of the infrastructure in a single place. And users can easily and securely access all of that infrastructure, all the necessary ones that they need access to through the same platform. All right, back to you, George.

George: Thanks. Yeah, and the Okta piece is critical. So what Xin just showed off to the side is that by default, everything's wired in to your IDP. So all the access controls that are applied at your IDP level are automatically applied everywhere else inside of your environment. So access control touches on a variety of different control families. And remote access is one of the first things that's scrutinized because it is the absolutely necessary backdoor into your environment. Any places where there's a gap where something doesn't meet the requirements is going to result in a POA&Ms, it's going to result in something that you're going to have to fix when talking to your sponsoring agency and when dealing with the PMO. Without Teleport, you're left with a variety of ad hoc solutions that teams will either implement themselves or that one centralized team will try to pull together to cover a whole bunch of different technologies. And that's just an immediate audit red flag right off the bat. And it's going to taint the rest of the questions that you're going to deal with throughout the rest of your audit.

George: It guarantees that there's going to be gaps and someone's going to miss something somewhere. And the remediation, the process to either remediate issues that are found during the audit or to get all these different technologies aligned is going to burn a ton of time that is best spent focusing on all the other FedRAMP requirements. With Teleport, centralized access control, everything is wired through Okta or whatever your IDP is. You have centralized user management. You can prove it right off the bat and you can demonstrate it. Couple of anecdotes here — what we've seen is that the Teleport admins for FedRAMP programs tend to spend more time in the audit hot seat than anybody else. Their controls are heavily scrutinized. And once auditors figure out, kind of wrap their head around Teleport and realize it's not a VPN. It's better. It does lots of things. They tend to really, really enjoy it. And they'll spend a lot of time grabbing screenshot after screenshot after screenshot, grabbing that audit evidence that they need that's all just right there. And that kicks off the audit in a way that is really positive, shows that things are under control.


George: All right, let's go to the next one here. All right, so do admin connections use FIPS? All right. If you don't know what FIPS is, congratulations. You've lived a blessed life up to this point. The short answer is FIPS 140-2 and soon 140-3 requires that your services’ crypto operations be done using a small handful of formally NIST-approved crypto libraries. Implementing this control is one of the most complex and time-consuming and frustrating parts of FedRAMP, which is really saying something. And since it's a government mandate, it is an absolute must-do. It is highly scrutinized. It is very easy to validate whether or not these libraries are correct and approved. So without — actually, let's just jump back one to the — keep it on the questions. Right. So without Teleport the answer to “Do your admin connections use FIPS?” is yes.

George: You end up saying things like, "We've converted our internal host to use Amazon Linux or shelled out the money to purchase Red Hat or Ubuntu Pro. So our SSH servers can use those distros FIPS-validated OpenSSL libraries, which was really painful because it forced us to get off things like Alpine and other simplified distros that have way less vulnerabilities, which now we have to deal with monthly as part of our vulnerability management, continuous monitoring processes. We've upgraded our VPN to FIPS, and then we've had to configure our jump boxes to also use FIPS, and then we've had to make sure that all of our applications and databases are recompiled or linked with the right FIPS mode, and that all the compilation steps meet the security policy of the particular FIPS modules. And lastly, that the FIPS certificates are all valid. And we're really, really hoping that none of them have gone historical or expired in the time since we last checked and when we're actually going through the audit right now." Again, it's a mouthful. It's not the kind of conversation you want to be having. Xin, what does it look like with Teleport?

Xin: Yeah, let me show you real quick. So we'll take a look at some of our available docs here. But basically, to ensure that all connections use FIPS-validated cryptography with Teleport, all you have to do is run Teleport in FIPS mode. So instead of doing Teleport start, you would just do `teleport start --fips`. So by enabling the `--fips` flag, Teleport will refuse to start unless all binaries are compiled with BoringCrypto, the FIPS-validated cryptographic module. So in practice, all an admin has to do is fetch our FIPS binaries and run them in production. And that will solve all your problems here.

George: Yeah. All right. Let's go on to the next slide here. So this is covering your admin connections, and that's important because the FIPS mandate is a mandate in the US government. You have to be able to prove it. You have to list every crypto module that you're using for each of your connections. Now an appendix queue for your submission package. And it's really nice to be able to say, "All admin connections from the internet to the perimeter use Teleport, and all connections from Teleport into those systems use the Teleport's BoringCrypto library." It makes that process a lot easier. If you're deploying the Teleport agent, SSH agent internal on your hosts, then you have the ability to do FIPS on hosts that don't have native OpenSSL, so that puts things like Alpine back on the table. Without Teleport, you're having to go service by service, figuring out how to deal with this for remote access. You end up in a potential situation where you have to go one by one or really prove across a bunch of your different hosts or remote access processes that all of them are doing FIPS. And you end up having to juggle tracking a half dozen or a dozen different crypto certificates that you need to keep track of.


George: Being able to show it — anecdotally being able to show it in one place. Like, "Here. This is in FIPS mode. Here's the client. It's compiled with BoringCrypto." It takes seconds and lets you move on with your life. And the fact that it automatically enables this once you turn it on is just one less thing to have to worry about. Let's keep going here. All right. Are there shared or break-glass passwords? So no matter how big your infrastructure is, the answer is yes, and that's just not good. But the part that really bothers anyone doing this is that you never really know all the places where the answer is yes. So in the audit, you'll have to do your best and hope that you're right enough. So when asked this question in the audit, the answer is yes, you have to say things like, "Our admins use shared passwords for a handful of our databases because there's no way to wire it into our IDP. There's also several applications like cache servers and other things we've deployed where we all have to share the same password to get access from our jump box."

George: Oh, and then, "We put a few of our internal systems into FIPS mode and that broke integration with SSO. So we have some shared passwords there because it's easier than managing individual users. But we do have a list of those users somewhere and we do clean them up when people leave or change roles sort of. And we're definitely sure that we shut down their access to the VPN right away so that they can't get access into the internal system. But speaking of the VPN, we do have break-glass accounts that we use in the case that the VPN goes down or our IDP gets knocked offline and we have to get access into the environment without it. We keep that username and password in a mumble, mumble, mumble. And only a few of us have access to that. And we make sure that whenever any of those people have to leave the company because they quit or were laid off or got fired that we change the password as soon as we find out because otherwise they'd be able to get access into our environment and burn it all to the ground." Which is the real honest answer. And I swear, going through that process and audits is like going to confession, only you feel more guilty after saying everything out loud. But you have to, right? You have to because you know the answer is yes. The auditors know the answer is yes because everyone always says yes. So Xin, what's the answer with Teleport?

Xin: Yeah, I mean, the answer is no. So to kind of expand on that a little bit, there are no shared passwords, and we don't actually even reuse credentials for the same user session to session. So when a user authenticates Teleport, they're issued a short-lived certificate. And if they log out and re-authenticate, they are issued a new short-lived certificate. So Teleport, just in general, doesn't use passwords, so there are no shared passwords. When we talk about the break-glass scenarios, so there are really two major break-glass scenarios. In the first scenario, your SSO provider is down. So in this case, when I hooked it up to our demo cluster, let's say Okta is down, right? So in this case, because your SSO is down, then users can't access Teleport. Do they need break-glass passwords? The answer is no because Teleport is a sample provider in itself. So you can simply temporarily use Teleport to authenticate. In the second scenario, Teleport is down. I hope not, but let's say it's down. Even then, as long as you have access to the root CA that is Teleport, which you should have access to, even if Teleport service is down, you can temporarily manually issue short-lived certificates for users who need to access things. And once again, you don't need to provide passwords. You don't need to implement passwords. You don't need to share passwords.

George: Yeah. And that's fun. That's a fun answer to give, right? And it's the kind of answer that is immediately met with scrutiny from auditors because they never hear it. But then when you get into the details and explain why, as they're wrapping their head around what it means to use Teleport, it actually makes sense. And it's really fun to see that dawning realization in an auditor's face that they aren't going to have to go into all the details about this, right? They aren't going to have to ask you to show the list of who has access to the shared passwords, to prove that you rotate the passwords, to prove that if someone uses one of those break-glass accounts, that you have a process to go through and detect that it was used and revoke their access and change it for everybody, and all of that. And it also sends the message to your customers and to the government that you found a way to do this that eliminates one of those most disconcerting backdoor access mechanisms that is so common in a lot of these environments. And it's really nice to be in that situation versus the alternative.


How do you implement concurrent session control, timeouts, login banners, ban-hammers, etc.?

George: Yeah. Let's keep going. All right. So for FedRAMP introduces, in addition to everything else we've talked about, when you start going through the controls line by line, you start finding that there's these very specific bits and pieces around session management that include things like a half dozen rules requiring you to do stuff that you wouldn't normally think to do. Like only allowing, I think it's three concurrent admin sessions, two or three concurrent admin sessions at a time. Having to issue a standard government-approved, sponsor-approved warning banner for all inbound connections, automatically logging people out, things that are tricky or sometimes just impossible to do on all the different technologies just because that feature isn't supported in them. So in an audit, it always ends up going something like this. The auditor will ask, "Do you do insert requirement here?" And you end up having to say like, "Yes, we do that everywhere except for x, y, and z, and let me explain why." And then you have to start talking about compensating controls for not doing that. And you have to start hand waving and giving technical explanations and hoping that the auditor will accept it.

George: Then eventually the auditor will say, "All right, show me that a particular control or process works on —" and they'll pick something from the inventory. And you end up having to take a deep breath and hoping that it's one of the ones where you have these controls fully implemented. And this is necessary because no systems, no applications out there that are being used in infrastructures were designed to meet all of these requirements. Auditors know this. They've asked this question dozens of times. And so you end up having to play that game where you try to convince them that you've done enough to have done a due diligence and done other things around it. And the more technologies that you have, the more service area that's just guaranteed you're not going to do all of them. Because at the end of the day, just about nothing has been built specifically to meet FedRAMP requirements for all these different finicky, very, very specific controls. All right, Xin, what's it like with Teleport?

Xin: Yeah, absolutely. So we have, as George mentioned — no product's kind of built for this. Well, not technically right because I think Teleport, in a lot of ways, we did build these specific controls and features just for this. So as an example, let's go through that list that George had up, right? First on that list was concurrent session controls. So we have built into Teleport these configs here, one of which is max submissions. So this actually limits the number, in this case, of concurrent Kubernetes sessions per user. But we can kind of apply this to any sort of session. And then we have — the next one on the list was timeouts, and we can take a look at our config file on timeouts. We have all various different types of timeout configurations. We have client idle timeout, we have web idle timeout, we have various other authentication timeout, login timeout, etc. So all of that is built into Teleport and propagated to the rest of your infrastructure.

Xin: The third one here is login banners. And we have that built as well, right? In here, there's a message of the day that you can configure, and that will be sent to users, whether they log in through the web UI, whether they log in through tsh, which is our command line interface for our desktop app, that is all propagated to them. And you can configure this as you need to. And then last one on that list was the ban-hammer. And we'll kind of go through a quick demo of that just to show down to the detail, basically how we built and implemented this according to FedRAMP. So I have, as you recall, this user here, this is an admin user. So we'll have that pulled up on one side. And then I have another user here. I'll put into view on the right side here, and this is a dev account. So this is a dev account, and then my original user here on different browser window is my admin account. So let's say this developer, so `dev-derek`. So let's say Derek starts doing some shady stuff, right? So let's say he logs into this Linux cluster, he starts looking at some — I'm doing some shady stuff here. He's doing hacks, etc.

Xin: So in this particular case, so as an admin, I can immediately go ahead and drop the ban-hammer on Derek. So you'll see the session is still ongoing, right? And then we'll go ahead and drop the hammer on that Derek right here. So we'll add an identity lock. Bye-bye. And as you'll see here on the Derek side, locked out. And if Derek tries anything — to try to refresh or anything like that to reauthenticate, now the entire account is shut off. And not only can we do something like that where we can sort of drop the ban-hammer on a particular user, we can actually do that on various different types of resources. So we did user there. We can do it on entire roles. We can do it on MFA devices. We can do it on specific Linux logins if they are privileged logins. We can do it on specific resources, right? Here we have servers, desktops, etc. So all of these different ways of locking your resources or locking your users or locking identities down, you can do that through Teleport and is immediately effective. So here, Derek was in a session, we put a lock on him, and then he got kicked out. So yeah, so we built all of these things with FIPS in mind. All right. Back to you, George.

George: Yeah, so the ban-hammer, the fact that they built the ban-hammer specifically for FedRAMP was pretty cool, right? And that's one of the things that auditors love seeing live. And it's fun to do to somebody that's in the environment and then apologize to them afterwards. "Sorry, we had to do that. We were proving it to the auditors." And being able to show and demo these features right off the bat. I mean, this is one of the places that causes Teleport admins to spend a lot of time in the hot seat because you have to go through and explain like, "How do you do session controls like this? Prove it. How do you do messages, the login banner like this? Prove it." And being able to just go right down the list and just tick these things off in one place saves a huge amount of time during the audit, saves a huge amount of risk that somebody somewhere inside the infrastructure didn't get the message where you need to put a login banner, wasn't able to configure session control on a database. And that just makes your life easier across the board. And one of the other features it's got is the ability, since you're doing this not only to interact with sessions like SSH, you can also do it for things like web UI access — it’s just a huge time saver for getting positioned to be able to meet compliance.


George: All right. Let's move on here. Okay, what audit logs do you have? All right. So audit logging, this is one of those places where the FedRAMP requirements manage to be both super specific and maddeningly vague. On one hand, the expectation is that you've got good logging, obviously, that you can access it, that it's full and complete. On the other hand, it's kind of unclear what actually needs to be logged, particularly when it comes to admin activity. And it boils down to do the right things, but you have to keep — you have to constantly figure out what are those right things across all of your different applications. So that means developers end up having to look at a generic list of actions that they need to be collecting and they don't really know what they mean, or you have to work from something like M2131 that's somehow managed to be 40 pages long and is still vague and not directly applicable in all places. So you end up getting into an audit, and the auditor starts asking you questions about all these different requirements, and things get weird, right?

George: You say things like, "Well, yes, we have a central SIEM, and that does security logging. And we've told all the engineering teams they need to configure their hosts and their databases and their EKS clusters and the cache services and their various AWS services to generate logs. And we've tried to make sure that all the teams actually did it and that all the agents are running properly and that the agents are configured to collect the logs out of the right directory and that the logging location wasn't moved, and that all of those are being sent to the SIEM. And then once they get to the SIEM, the SecOps team or SecOps person has to collect all of them in one place so they can do analysis and build dashboards and generate alerts and that requires parsing out dozens of different log formats which hopefully haven't changed in the recent app updates." You say all that, then the auditor pulls up the inventory, picks a host at random and asks to see the logs, access logs of that particular host. And then you call up your SecOps people and you hold your breath and you hope that they've got this. There's a lot of places things can go wrong. Xin, what's the Teleport tale?

Xin: Yeah, so we talked about how everything is in one place, right? All of your resources. Here, I'll pull up my admin account once again. So we talked about how all of your resources in one place, you can enroll a bunch of different resources. And the nice thing you get from that is since we are actually implemented at the protocol level. So at the SSH level, at the SQL level, at the Kubernetes level, we actually have all those audit logs. So remember when just earlier, we had Derek go into a session, do some shady stuff, and get ban-hammered. So we can actually take a look at that entire end-to-end process, right? So we see here that Dev Derek got a certificate issue. They logged in. They started a particular session. A log was created by myself. The client got disconnected, etc. So we kind of see this end-to-end process in the auto log. And then if we want to go and investigate exactly during this particular session, this session right here, what Derek did, we can actually go in one layer deeper and look at the session recordings. So here we have a session. This is the session ID that was referenced in the autolog. We can actually take a look and replay this back, right? So we saw exactly everything that I did here. We went into the session, did some shady stuff, time elapses, and then got disconnected. So you can investigate this down to list level of detail for all the protocols that we support.

George: All right. Yeah. And having all of it in one place, all your audit logs in a uniform format across all the different platforms is huge. Being able to export one format into a SIEM makes it really easy to build and generate — let's go to the next slide. Makes it really easy to build and generate dashboards of account activity. You can see when bans are issued. You can see when a particular user's logged in. You can answer those questions that are coming from an auditor as you're going through. Without Teleport, without a centralized solution, it's like playing whack-a-mole and you never know how many moles there are out there. And the session recording is a requirement for FedRAMP high. It's really fun to have if you're doing something like FedRAMP moderate. And that solves the problem of what admin activity should be logged. We're logging everything that admins are doing, we're collecting, we can play it back, we can review it, we have that capability. So it eliminates that vagueness and it cuts down one more thing that engineering needs to worry about and deal with. Let's keep going.

George: Okay. So we have these five questions. We've gone through them. We've talked about them from the audit compliance sort of view, the big scary thing that you have to do the first time and the unnerving thing that you have to then do every year after that or whenever you're doing an SCR. But I'd also like to step back and point out that these are also engineering questions that have to be answered, particularly when you're first building out your infrastructure. Solving initial access control is critical before you can access the hosts that you're actually deploying. So it's step one, if you're building out your infrastructure and getting that sorted out upfront can either burn a ton of time while engineering is blocked or it could be done very quickly. Once you figure out that you need to do remote access, you need to figure out how to answer the FIPS question for that remote access Teleport. It's a command line flag. As you start building out your infrastructure, all those places where teams who are moving things in from commercial would otherwise set up their standard shared password or their glass passwords. They don't need to. So you can build an environment that from the beginning does not have, and does not need to have, those shared or break-glass passwords, which makes it possible to decisively say, "No, we don't. We built this without having to need them."


George: You get all these finicky FedRAMP-specific controls implemented in one place in one YAML configuration instead of across dozens and dozens of different applications and servers and services. And you solve audit logging, which is just one last thing that engineering needs to worry about. Let's keep going. FedRAMP's really hard. It's really, really brutally hard. And being able to proceed through the build of your environment, proceed through the operation of your environment with these things from an admin perspective handled. These controls, just nailed, free you up to think about all the other challenges that you have in maintaining this environment. And reducing that burden on engineering, reducing that burden on security and compliance is huge. And the Teleport folks have gone through for each of these controls. They've given the pithy short answers for each of them in explaining how they do these things to position your security, your compliance people who are going through these processes with auditors to know exactly what answers they need to give, to give the folks who are deploying these technologies the information they need to know to configure Teleport, to meet the FedRAMP requirements. It's there, it's ready to go. Let's keep going.


Centralized access control — rollout timelines