Simplifying FedRAMP Compliance with Teleport

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.

What You'll Learn:

• 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.
  

Who Should Attend?

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?
  • How do you use FIPS for admin access?
  • Are there any shared or break-glass passwords?
  • How do you implement concurrent session control, timeouts, login banners, etc.?
  • What audit logs do you have?
• 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

• Teleport Access
• Teleport Identity
• Teleport Policy
• Teleport Device Trust
• Teleport Machine ID
• Teleport Passwordless
• Teleport Server Access
• Teleport Application Access
• Teleport Kubernetes Access Guide
• Teleport Database Access
• SAML Identity Provider Access
• Teleport Workload Identity

Transcript - Simplifying FedRAMP Compliance with Teleport

George: Morning, everybody.

[silence]

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

Xin: Yep.

George: Cool.

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

[silence]

Introduction

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?

[silence]

George: This is fun. It's like a race.

[silence]

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

[silence]

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

[silence]

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.

What could go wrong

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.

Five FedRAMP compliance questions

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.

Do admin connections use FIPS?

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.

Are there any shared or break-glass passwords?

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.

What audit logs do you have?

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."

20 Fewer things to worry about

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

George: And no one's ever said, "Man, I'm sure glad we had all that time to do a FedRAMP program. Timelines are always critical. And going back and forth with Anna and Xin and some of the Teleport folks, and we talked about this idea of what does a timeline look like with and without Teleport. If you're having to build this from scratch or having to consolidate on one centralized access control process inside your environment, you have a long slog ahead of you. You have to go through a discovery process to figure out what's everybody using, what does everybody need? Then you have to decide on one and figure out a path forward and get people aligned on it. You've got to build that up so it's ready to go. You got to roll out and convert everybody to use this, which introduce all sorts of risks for things to not work, for it to block engineering, to not meet the requirements. You've got a long tail of troubleshooting before you can get to GA, and then eventually you either disable the old services or you no longer need them. The Teleport timeline is just so much shorter.

George: You make the decision that you're going to use Teleport, "Great. Everybody, we're using Teleport." No need for discovery. Any existing services people might have in the environment, they can keep using. You can then roll out Teleport in place. If you're doing this from scratch, you set it up first as teams populate the environment. They wire in Teleport. If you're rolling this out in an environment that has already gone through FedRAMP certification, you can keep your existing mechanisms in place. Roll up Teleport alongside it. Once everything's been troubled — you finish troubleshooting, everybody's happy with it, you can then disable those old services. So you're able to keep what's been working well enough for you while you roll out something better, and then shut those other things down when you're done. Next slide. All right. Yeah, that's everything I've got here. Thanks, everyone, for taking the time. And Xin, back over to you.

Xin: Cool. Hey guys, before we move on specifically to Q&A here, we do have a short survey. If you have some time, please fill it out so we can improve these webinars for future attendees. With that said, I think we have a couple questions in chat here. I'm going to stop sharing so Lexi can pull them up. Lexi, you want to — all right.

Q&A

George: Yeah, so I can answer this certainly on the revoking live sessions. So Xin showed revoking live sessions. And it's a good question. Xin, do you have the answer? If you change someone's permissions while they're live, does that reissue the certificate? I thought the certificates were like five — you can set them to be like five minutes.

Xin: Yeah, so they're revoked. They're revoked, yeah, in this [inaudible]. That's why even though the session timeout hasn't occurred, the TTL, we haven't hit that TTL on that account. It was immediately kicked out. And then on trying to authenticate, it was denied. Otherwise, if we just let it expire instead of revoking it, then that person would have another hour or whatever the TTL is configured to be to have access to that.

George: Yeah, and I believe we've set the key rotation down to like five minutes to be able to say, "Yeah, this thing can — you have to go through a TTL every five minutes." And that would catch change of permission saying like, "This person no longer has a properly signed certificate to get access through this system."

Xin: Yeah, we go even further than that. So I believe you can set it to as low as you want, actually. And then there is a maximum. So for some of the timeouts, the maximum is like 24 hours or 48 hours. So we won't allow a value greater than that for the purposes of making the defaults easy for you to configure, right? And then on top of that, we go above and beyond in terms of functionality to support your audits. So we do things like per-session MFA. So not only are you challenged for multi-factor up on authentication through Okta, but now we can also challenge certain users or users accessing certain resources for their MFA tab on every single session that they try to open. So there are also things like moderated session where you can only access something if someone else is there, right? And there's like role criteria that you have to hit in order to actually access something. So there's a lot of ways to configure. There's also device trust that you can only access something with a managed hardware that is registered with your company. There's a lot of different things that we can do here to lock it down even more than we've shown in the demos today.

George: Okay. And we have a couple of questions about FedRAMP authorized and FedRAMP certified. So that's a really good question. So the Teleport runs inside your boundary. And so it does not need to have its own FedRAMP certification. We're not talking about right now the SaaS-hosted version of Teleport. For FedRAMP compliance, you need to stand up your own Teleport clusters inside your ATO boundary. So it's on-prem in-boundary software. So it doesn't require its own FedRAMP certification. It needs to be able to demonstrate that, since it's software running inside of your boundary, it meets all the FedRAMP requirements, which it does. Obviously, it meets FIPS and does all the access control things, all the logging, etc., etc. So you run it inside your boundary and it doesn't need its own separate ATO.

Xin: Yeah. So there's a question here from Jacob around other support. So a lot of what I demo today is in the web UI because it's easy to demo and we only have finite amount of time for our webinar today. But yes, to answer your question, we do support other applications. We have a native terminal application. You might have mentioned — you might have heard me mention something about our CLI. So we have a command line interface client called tsh. You can use tsh to do all the things that we did today. `tsh login` logs you authenticate [inaudible]. Right. `tsh db connect` connects you to a database. There's Kubernetes commands that allow you to issue kubectl commands, etc. So that is supported. On the database GUI side, yes, I answer the same thing again, but you can essentially use Teleport tsh to start a proxy with a database and then set up and then as long as you configure the ports correctly in your database GUI, once that proxy is up, you can then access database resources as you would normally. We'll take another two or three questions here because we're running a little bit late on time. But yeah, we'll take another couple questions.

George: Yeah, Thom was asking about, yeah, real-time security logging. So the mechanism there is the Teleport logs can be exported directly into a SIEM. So Teleport itself, and Xin, correct me if I'm wrong, I don't know if y'all have built real-time alerts into the product itself, but the option that you have is if you already have to have a SIEM running inside of your environment, you can export the Teleport logs, standardized format, and then build real-time alerts based on whatever you want, whatever metrics you have, whatever capabilities your SIEM has to generate alerts through that.

Xin: Cool. All right. We'll take one last question here. When will Teleport be FedRAMP authorized? So we just got done with our slew of different audits, but FedRAMP is not one that we're currently doing, but it is something we will definitely invest in, in the future. It is not one that we're currently undergoing.

George: Yeah, and to make it clear, all the examples I've been giving and kind of the things I've been talking through has been based on the Teleport's on-prem deployment, right? So there's Teleport Cloud, Teleport Access Platform that is the SaaS hosted version. And that does not have a FedRAMP certification. My experience so far has been running Teleport clusters inside the ATO boundary, where we explain to auditors and to the PMO and various other groups, like, "This is not a SaaS hosted platform. This is replacing the VPN that you would normally see on the off-boundary diagram."

What’s coming up

Xin: All right. Cool. So that's all we have for questions today. And then I'm going to pull up one quick slide here.

[silence]

Xin: George, do you want to speak to some of the upcoming things?

George: Yeah, so these are some ideas we've been kicking around for other things that could help folks working with Teleport and FedRAMP. Going through and putting together SSP to system description. Actually, Xin, could you mute your mic? I think something's coming through on your end. So going through and writing up, what would a system description describing what Teleport is and how it works, look like for places where there are specific control write-ups, like the 20 or so that we had listed earlier, what would some language look like? What would the language look like for explaining this is how Teleport works, this is how it's operated? Then just to give folks who are looking at Teleport for FedRAMP or who are deep in the FedRAMP process and know what an SSP is and what the control writeups look like, just make it that much easier for folks to slot that in. And then also putting together some of the Teleport-specific configuration. The Teleport YAML file is pretty straightforward. The features are all there to enable all these different things that you need for FedRAMP compliance, pulling together one that just has it all in one place. So anybody looking to launch this inside of a FedRAMP boundary could start from that and get a lot of the things like session banners, various timeouts just configured by default and have something to start from to get underway. So stay tuned for that. It's been interesting. And thank you very much, everybody, for taking the time today.

Xin: All right. And lastly, we do have our next webinar already scheduled for July 11th at 9:00 AM. The topic will be Hardening Infrastructure Security Against SSO Identity Provider Compromise. We actually have our CEO presenting with some other folks from Doyensec who we've partnered with on a lot of this — a lot of this content. So you can follow the link here to register or there should also be a banner across your screen right now that you can click on to register for our next webinar. All right. Thank you guys for attending today. Appreciate your time. Hopefully, this was a useful and helpful session for you. And yeah, join us for our next one. Thank you.